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Introduction 


I find working as an automated lighting programmer a truly wonderful career 
choice. Sitting at a console controlling many moving lights and exercising 
my creativity is pure fun and extremely rewarding. It also enables me to travel 
throughout the world, meet many different people, and work on all types of 
productions. Each event presents a different set of challenges and opportunities. 
I always enjoy sharing my knowledge in this field with others and hope to do 
just that with this book. 

Automated lighting is a fairly new development in our industry, and there 
are many who are only now beginning to explore this field. With this book, 
the plan is to share basics of programming automated lighting fixtures while 
also providing useful information for those who have been working with this 
technology for several years. Much of this information comes from my own 
experience and knowledge. In addition, many esteemed programmers and 
designers have been consulted to ensure that the data is accurate and timely. 

Because this book is a guide strictly on the process of programming, which 
is essentially the same regardless of the fixture and console types, there is no 
mention of specific manufacturers’ fixtures or consoles (except in the Appen- 
dixes). Specific console syntax and fixture operations can be studied via the 
user’s manuals provided by equipment manufacturers. The basic principles pre- 
sented within this book apply to past, current, and future lighting technologies. 

Programming automated lights is very much an art. Just as almost anyone 
can learn to hold a paintbrush and put paint on a canvas, the actual entering 
of data into a lighting console is fairly simple. The real art comes from years 
of experience, fine-tuning the procedures for painting the canvas or program- 
ming the console. Similar to painting, there is no right or wrong way to pro- 
gram, only the requirement to get the data into the desk in a method that 
produces the best show possible given all the constraints. 

If you have ever wanted to know what goes on at the lighting console, or 
have a desire to become an automated lighting programmer, then please read 
on and enjoy. 
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10 Things Every Programmer Should Know 


There are many things that every automated lighting programmer just ought to 
know. These basic concepts and routines help to create the groundwork for any 
production’s lighting. A solid understanding of the following should help any- 
one interested in programming moving lights. The following is presented in no 
particular order. 


#1—UNDERSTANDING THE FIXTURES 


When starting with a new rig, you should first find out as much as you can 
about the fixtures you will have. Download the manuals and read up on the fea- 
tures and functions of the lights. Study the fixture’s digital multiplexing (DMX) 
protocol so you understand what happens to the fixture with different DMX 
values. A good understanding of how the fixture responds to DMX (and 
what is available) will aid in any programming. In addition, studying the differ- 
ent modes and options of the fixtures can result in optimal settings for your 
production. 


#2—BASIC CONSOLE OPERATIONS 


Of course, if you do not know much about your console, how can you be 
expected to program it? You do not need to be a full-fledged expert on every 
aspect of the desk (although this does not hurt), but at the very least you 
must be able to patch, create cues, recall cues, and backup the data. 


#3—PATCHING AND ADDRESSING 


Once you have studied the fixtures and grasped the concepts of your console, 
it is essential that you know how to connect the two together. Properly patching 
the desk and addressing the fixtures is a skill every programmer must possess. 
The more information you can provide to the crew about the patch, the 
better. Too often I have seen productions where the programmer did not create 
a patch until he or she was on-site, leaving everyone was waiting around for the 
information. 
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#4—MAKING LIGHTS MOVE 


The most basic function you should be able to accomplish is to move fixtures 
from point A to point B using a repeatable method. Generally, this requires two 
cues or steps of a chase, one with the fixtures in position A and the other with 
the fixtures in position B. Then by crossfading between the two cues, the fix- 
tures will move at the selected crossfade speed. You can then apply these pro- 
cedures to the other parameters of your fixtures. 


#5—LONG HOURS AND LATE NIGHTS 


Our industry often gives the lighting team the late night shift, so you must be 
prepared to spend many long nights at the console. Knowing how to prepare 
your body and mind for hours of staring at one canvas, while helping to create 
multiple paintings, is essential. 


#6—SUBTRACTIVE VERSUS ADDITIVE COLOR MIXING 


The most common color mixing in moving lights uses three graduated dichroic 
filters: cyan, magenta, and yellow. By combining the three you can create millions 
of colors. This is usually called subtractive color mixing because you are remov- 
ing (or filtering) wavelengths or colors out of white light. As more wavelengths 
are subtracted, the color tends to move closer to black. On the other hand, additive 
color mixing is generally accomplished by adding several sources together to get 
closer to white. For example, most light emitting diode (LED) fixtures use addi- 
tive color mixing by combining red, green, and blue sources. 


#7—TRACKING 


Conventional lighting desks commonly record all values for all channels into 
every cue. Moving light consoles make use of tracking by recording only chan- 
nels with changed values into each cue. This significantly reduces the amount 
of data in each cue and enables many tricks for dynamic programming and 
playback. 


#8—PROTECT THE DATA 


A good programmer will protect the data in the console with his or her life. You 
are hired to enter the data into the console, and to see that it remains there (or 
can be recalled) at all times. Proper saving routines are essential as well as 
requiring an uninterruptible power supply (UPS) and a dedicated power source. 
If something goes wrong and all data are lost and you have no options for 
recovery, then only you are to blame. 
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#9—HOW TO ADMIT YOUR FAULTS 


If a lighting designer (LD) asks for a particular effect or look and you are unsure 
of how to create it, admit it. Do not tell the LD that it is not possible; either find 
a way to make it happen or tell him or her you do not know how to do it. One 
LD has told me of a time when his programmer said the console could not select 
fixtures based on their current color. The LD told him it was possible, as his last 
programmer did it all the time. Again the programmer said it was not possible 
and told the LD he must be mistaken. The LD called his last programmer and 
had him explain to the current programmer how to do the function. Needless to 
say, the LD never wanted to hire this guy again, although things would have 
been different if he had just admitted that he did not know how to perform 
the function. 


#10—WHO TO CALL 


Write down the support phone numbers for all the lighting manufacturers and 
keep this list with you at all times. Then when a problem develops, or when 
you need to know how to do something, call for assistance. Do not call instead 
of picking up a manual and trying to figure it out, but do call once you have 
exhausted other methods. In addition, there are many people in this industry 
who like to share their knowledge. Get to know others and network. I know 
of a group of programmers that try to get together once a month just to share 
experiences and problems with each other. This way they can all learn from 
one another. 


BUT WAIT! THERE’S MORE... 


Sure, there is plenty more you need to know to be a successful automated light- 
ing programmer. This book is filled with many of the basic concepts that you 
need to get you started. The most important thing to remember is that you are 
working on one element of the show, and to strive to make your part of it the 
best it can be for the overall production. 
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The automated lighting programmer must have many skills beyond knowledge 
of simple programming syntax. The position requires that one evaluate each 
situation to determine the right method of operation. Some productions hire a 
programmer to handle all aspects of the lighting, while others hire a program- 
mer to bring a lighting designer’s (LD’s) vision to life. Real-world experience 
with many productions is the only way an automated lighting programmer can 
become successful. Knowledge, speed, accuracy, people skills, and so on are all 
vitally important, but there is no substitute for experience. 


THE AUTOMATED LIGHTING PROGRAMMER 


There are many different levels of productions, each requiring specific types of 
people on the production staff. Understandably, there are several different cate- 
gories of automated lighting programmers. Each holds an important position 
within our industry, by providing different levels of experience and knowledge. 

First, there is the weekend warrior. This type of person simply programs 
lights for fun, but has another main profession. The weekend warrior has little 
to no interest in learning more about the profession. 

Next is the amateur programmer. Amateur programmers program lighting 
when and where they can (schools, churches, clubs, raves), but programming is 
not their main source of income. They have an interest in the profession and 
strive to learn more about automated lighting programming. 

The apprentice programmer is involved in the lighting industry and 
programs whenever there is an opportunity. Oftentimes apprentice programmers 
are hired to work on productions in positions other than lighting programming 
(technician, followspot operator, etc.). They have a desire to gain as much 
programming experience and comprehension as possible. 
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A professional programmer earns his or her living by programming 
automated lighting. The majority of this person’s income (80-90%) is from 
programming. Automated lighting programming is the chosen career of pro- 
fessional programmers, and they continue to study and improve their skills as 
much as possible. 

Finally, the professional programmer/designer works regularly as either a 
lighting programmer or lighting designer. Oftentimes this person will be hired 
onto a production filling both rolls simultaneously. The income of this profes- 
sional is split between programming and design. Continued improvement of 
knowledge and experience is continually sought by this career type. 

Of course, like most jobs in the entertainment industry, some people will 
work on high-profile productions (award shows, Broadway, large tours, televi- 
sion shows) and get lots of press. Their names will be well known in the industry 
and they will be mentioned in magazines and on websites. Others will do many 
shows, but will not be well recognized within the industry. Yet these individuals 
will still be successful programmers with a grand career. 


THE HOLLYWOOD SYNDROME 


Our industry is only a small part of “show business,” yet it still lives up to 
many of the clichés. Many students and apprentices of the profession expect 
a fast track to the “big” shows. They see the concert tours roll through town 
and the live television broadcasts and think, “I can do that.” Oftentimes 
these people will begin working with a lighting company and will not under- 
stand why they are not going out on the next big U2 or Rolling Stones tour as 
the programmer. 

There is a good reason you see the same programmer’s names on all the big 
shows: experience. While anyone can learn which buttons to press on a console, 
it takes many years of programming to learn how to get the most out of your 
fixtures, work with different types of productions and LDs, and handle any 
situation that is thrown at you. Ultimately, the actual data in the console is 
not what is important, but rather the end result. If you are able to create the 
LD’s vision in a timely manner and write the cue so that it is repeatable, 
then the methods of the data creation and storage are not essential. 

Recently, I was hired to program a live television special. The LD hired me 
because we have worked together before and he knows that I will come to the 
event and simply do my job. I have learned from my experiences not to wait for 
him on every detail of the show. He knows I will create original looks that fit 
with his style and work for the television camera. In fact, he even told me that 
he is not worried about what patterns are in the fixtures, as he knows that I will 
“work my magic and create new visual images.” If I had only programmed one 
or two shows in my life, he would not have wanted to hire me for this produc- 
tion. There is an extremely short amount of time from load in to taping, and he 
has no time to sit with a programmer to describe every bit of the show. So do 
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not be in a hurry to jump into the “big shows.” Instead, take your time and work 
hard, and the large productions will come to you. You will learn more about 
lighting on every production you are involved with and you should enjoy all 
the new challenges. 


CREATIVITY AND CONSISTENCY 


Usually lighting programmers are hired not only to assist in the creation and 
storage of an LD’s vision, but also to share in the creative process. It is 
extremely important that an automated lighting programmer is both left- and 
right-brained. It is often said that one side of the brain is technical and the 
other creative. A programmer must be able to derive original looks, concepts, 
chases, and then utilize the tools at hand to bring these ideas to life. Whether 
you are a highly creative person or not, there are many books and exercises on 
the subject of creativity. I strongly recommend exercising your brain as much 
as possible. 

The technical side of a programmer’s brain must contain the data needed to 
properly use a console and fixtures. In addition, regular, consistent routines 
should be used in console setup. For example, if you always number your colors 
or positions in a particular order, then no matter what show or console you are 
using, you will know that color 3 position 5 equals “down center stage red.” Do 
not just randomly lay out your console with each show. Of course, there will be 
aspects specific to each production, but if your basic building blocks are the 
same, then your programming will be much faster and efficient. 


LEARNING TO PROGRAM 


Once, while I was in Tokyo, Japan enjoying fine food with friends, we 
discussed the puffer fish (fugu). If the puffer fish is not properly prepared, 
then it can lead to tetrodotoxin poisoning, which has a 50% mortality rate. 
In Japan, only specially licensed sushi chefs are allowed to prepare and 
serve this dish. In fact, the U.S. Food and Drug Administration (FDA) allows 
properly prepared portions of the puffer fish into the United States only two to 
three times a year. The FDA’s agreement with Japan states, “Experience has 
shown that the best method for obtaining a product which will not cause illness 
or death is the highly specialized training and knowledge for product prepara- 
tion.” Although an extreme analogy, automated lighting also should not be 
taken lightly. 

Luckily, the mortality rate for improper programming of automated lights is 
extremely small—although I know some LDs who have wanted to kill their 
programmers! However, lighting programmers must practice their craft and 
continue to learn. Consoles are always improving, new fixtures are released, 
and creative visions change. There are many resources to help you learn how 
to program, but practice makes perfect. 
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Look for Opportunities 


Instead of waiting for the next gig to hone your skills, you need to find other 
avenues. The first place to look is your local lighting shop. Many companies 
will be willing to allow you to come to the shop and use a desk. While they 
may or may not have fixtures for you to plug in, at least you can use the con- 
sole. And, as a bonus, when you are hanging out at the shop, you might just 
be offered a gig. If you can get your hands on a desk, build a practice show 
from scratch with cues and everything. Do not just sit in front of the desk and 
poke around. Put yourself into a real-world situation and complete the required 
tasks. 

If you do not have access to a console, you can always make use of offline 
editors. Most automated lighting consoles have applications for the personal 
computer (PC) that emulate the desk. Using this software you can practice 
the syntax and procedures of the console. In addition, many of the offline 
editors now either include visualization or work with popular visualization soft- 
ware on the same machine. This means that you can sit at home and program 
virtual lights on a virtual console with your real computer. 


Programming Exercises 


The main reason to exercise your programming skills is so that the console 
functions become second nature, allowing you to spend more time being crea- 
tive. When you do not have to think about how the console works, an amazing 
ability comes through. You find yourself simply commanding the fixtures to 
create the desired looks without thinking about how to enter the data into the 
console. Of course, there will be times that you will be challenged by the 
console, but the more comfortable you are with the programming syntax, 
the better. 

There are many types of exercises you can do, and I will suggest my favor- 
ite. Put yourself into the following scenario. You have been hired to program 
the lighting for a small 2-day business meeting using about 20 fixtures. Late 
in the first day, the client surprises you by informing you that a band will 
play during the lunch break the next day (a 1|-hour period). The client wants 
you to “do lighting” for the band. It is now 7 p.m., and you can only be in 
the venue until 10 p.m. So you have 3 hours to program lighting for a band 
that you know nothing about (not even what type of music). 

The exercise is to program 20 fixtures for 2—3 hours to prepare for this sur- 
prise. Then ask a friend to grab a mixed collection of compact discs (CDs). 
Have your friend randomly select a CD and song and play it for you. Alter- 
nately, you could use a random playlist on an MP3 player; just ensure that it 
plays various types of music. Play back your programming to the various 
music types. Then have your friend randomly select another CD and song 
and play back to that one. Keep doing this for about an hour, and you will 
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find out whether you prepared yourself (and your desk) for anything that might 
come up. I find this exercise to be very consistent with real-world situations 
where you have to program and operate lighting for acts you have never seen 
or heard. 


Explore Your World 


A large part of being a good programmer and operator has nothing to do with 
the console. Your timing, rhythm, listening, visualization, and many other skills 
are just as important. Many of us often can’t help but imagine lighting cues 
while listening to music, but how often do you really listen to the beat, changes, 
and so on? Instead of trying to visualize the look of the actual lighting, try just 
thinking about when to trigger the different cues. Learn to anticipate changes in 
the music and recognize musical elements. Listen to all types of music, not just 
what you like. Even though your production may not contain musical elements, 
these skills will come in handy in most situations. 

You can also exercise your mind by trying to think of ways to recreate nat- 
ural lighting conditions. Pay attention to how the quality and color of light 
changes during a sunset or sunrise. One day watch a sunset on the horizon 
for 20 minutes, and then the next day watch a sunset on the side of a building 
or a tree. Sit in a dark house during a lightning storm, paying attention to 
Mother Nature’s lighting chases. These exercises will pay off even if you do 
not recreate these actual situations on stage, because they might inspire you 
to create an effect in a different manner. 


Never Stop Learning 


If you think you have mastered a console, think again. There is always something 
new to learn. Talk with others to see how they accomplish certain functions. 
Also, try doing things in different ways. For example, if your desk has a very 
strong effects package, try building a simple 30-step chase “old-school” style. 
You will find yourself someday in a situation where an LD wants an exact 
look that cannot be created using effects. For example, while I was working 
on an ice skating show the LD asked for a very specific chase. I thought I 
could build it with effects, and he thought it would have to be programmed as 
a chase. We were ahead in our programming schedule, so he gave me the time 
to try to create it with the effects. He was correct—it was not possible. I then 
quickly built the chase as a 90-step cuelist and it did just what he wanted. Luckily, 
I had the experience and knowledge to create this monster chase in a hurry. 


Be an Artist 


There is a true art to programming automated lights. It is a skilled craft that 
requires many years of experience to fully master the possibilities. Because 
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every production has its own unique challenges and requirements, the 
programmer must be fully confident in his or her abilities with the console 
and fixtures. Yes, we are part of the creative arts, but we also perform a 
highly technical job. Just as a fine sushi chef must train for years to perfect 


the slicing of a puffer fish, we must maintain a high level of craftsmanship for 
our profession. 
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Before studying the practice of programming automated lights, you should 
be familiar with specific concepts associated with automated lighting. Having 
a good understanding of the principles involved will open the doors to better 
programming. The following topics provide a basic understanding of the 
most important concepts related to automated lighting programming. 


DMX-512 


Most automated lighting fixtures use an industry standard language known 
as DMX-512. This signal specification allows for 512 discrete channels of 
control per data line or universe. Each of these control channels has the potential 
to be any value from 0 to 255. Originally designed for controlling dimmers, zero 
was mapped to 0% intensity and 255 was mapped to 100% intensity with a linear 
dispersion of all values in between. Generally, this is still the case with dimmers, 
but DMX is also used by automated lighting fixtures. Each parameter of a 
fixture (pan, tilt, gobos, color mixing) is assigned a particular DMX channel. 
As the value for this channel changes, it will affect the specific function 
of the fixture. For instance, a gobo channel might assign no gobo at a value 
of zero, while a value of 25 will output the first gobo. A value of 50 will 
output the second gobo, and a value of 75 the third. This mapping will 
continue through all 256 values of the DMX channel. The mappings of DMX 
channels to their functions for a specific fixture is known as the DMX protocol 
of the fixture. 
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DMX PROTOCOLS 


The DMX protocol of a fixture is the mapping of parameters to specific DMX 
channels (see Table 2.1). For example, if a fixture uses 8 channels of DMX, 
channels | through 4 might be used for pan and tilt (some parameters such 
as pan and tilt use 2 DMX channels each for a finer resolution of control, 
which is also known as 16-bit), channel 5 for dimmer, 6 for gobos, 7 for 
color, and 8 for shutter. Each individual fixture of this type needs to use 


TABLE 2.1 Sample DMX Protocol 


DMxX Channel Purpose Ranges 

1 Pan coarse 0-255 

2 Pan fine 0-255 

3 Tilt coarse 0-255 

4 Tilt fine 0-255 

5 Intensity 0-255 (0 is no output and 255 is full output) 

6 Gobo wheel 0-10 no gobo 
11-30 gobo 1 
31-50 gobo 2 
51-70 gobo 3 
71-90 gobo 4 


91-110 gobo 5 
111-130 gobo 1 shake 
131-150 gobo 2 shake 
151-170 gobo 3 shake 
171-190 gobo 4 shake 
191-210 gobo 5 shake 
211-230 gobo wheel spin clockwise (linear) 
231-255 gobo wheel spin counterclockwise 
(linear) 
7 Color wheel 0 no color 
1-19 no color + 1 (linear) 
20 color 1 
21-39 color 1 + 2 (linear) 
40 color 2 
41-59 color 2 + 3 (linear) 
60 color 3 
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TABLE 2.1 Sample DMX Protocol—cont’d 


DMxX Channel Purpose Ranges 


61-79 color 3 + 4 (linear) 
80 color 4 
81-99 color 4 + 5 (linear) 
100 color 5 
101-110 color 5 + no color (linear) 
111-130 color 1 shake 
131-150 color 2 shake 
151-170 color 3 shake 
171-190 color 4 shake 
191-210 color 5 shake 
211-230 color wheel spin clockwise (linear) 
231-255 color wheel spin counterclockwise 
(linear) 
8 Shutter 0-10 closed 
11-90 periodic strobes (varied speeds) 
91-150 random strobes (varied speeds) 


151-200 random synchronized strobes (varied 
speeds) 


200-220 fixture reset (hold for 10 seconds) 
221-230 lamp on (hold for 10 seconds) 
231-240 lamp off (hold for 10 seconds) 
241-255 open 


8 unique DMX channels within the universe total of 512 channels. The first 
channel each fixture uses (of its 8) is known as the fixture’s DMX start channel, 
or DMX address of the fixture. When using three of these fixtures, you will 
need to address them at 1, 9, and 17, and you will be using DMX channels 1 
through 24 to control them. 


FIXTURE MODES 


Not all fixture protocols are created equal. A fixture might have different modes 
that allow various functions of the fixture. For example, a 16-channel wash light 
might have a 14-channel mode, a 16-channel mode with normal functions, a 
16-channel mode with special functions, and an 18-channel advanced mode. 
It is very important to choose the mode that will provide the functionality 
you need for your show. Then each fixture must be set to this mode via its 
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menu system or dipswitches. Most automated lighting consoles make use of 
fixture libraries that assign the programming features of the desk to the proper 
DMX channels for the fixture. When patching you must make sure that the 
fixture library you use in the desk matches the mode assigned to the fixture. 
If you use the 14-channel mode library in the desk but assign the fixture to 
the 16-channel mode, you will have problems controlling your lights. It is 
essential that you study the protocols of the fixture as well as the fixture 
libraries of your desk to ensure not only that they match up, but also that 
they provide the functionality you desire. 


CROSSFADE 


When programming a lighting console, values are sent to specific DMX chan- 
nels for controlling the fixtures. For example, if you program a CMY (cyan, 
magenta, yellow) color mixing fixture so it is color mixed to a green color, 
the console will assign values to cyan at 255 and yellow at 255. Now if you 
want to dissolve to yellow, you will need to change the cyan value to 0. By 
assigning a crossfade time to the change of cyan from 255 to 0, you will 
cause the console to send all values between 255 and 0 over the period of 
time specified. This linear change of values is known as a crossfade. 


BUMP 


A value change with a time of zero is known as a bump or snap change. If in 
the preceding example the crossfade time was set to 0, then the console would 
instantly change the DMX value of the cyan channel from 255 to 0 without 
sending any other values. This would result in an instantaneous change from 
green to yellow. 


PARAMETER ABILITIES 


Some fixture parameters are fully crossfadable, while others allow for only snap 
changes. By reading the DMX protocol provided by the manufacturer, you can 
determine whether a function is crossfadable. Generally, a continually variable 
(linear) parameter can be crossfaded, while a parameter with indexed values 
will not be crossfadable. Looking at the sample DMX protocol (see 
Table 2.1), one can see that the gobo values are indexed and not crossfadable. 
Because each gobo has a range of values assigned to the full gobo, crossfading 
from 51 to 75 will cause the fixture to snap from gobo 3 to gobo 4. Crossfading 
is possible with the color wheel because the DMX ranges allow for linear posi- 
tioning of the color wheel. Crossfading from 40 to 60 will scroll from color 2 to 
color 3 on the color wheel. 
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PRECEDENCE (HTP AND LTP) 


When an automated lighting console changes the values of a parameter for a 
fixture, usually the most recent change has the highest priority. For example, 
if the first playback or cuelist points a fixture to stage right and the second play- 
back moves the fixture to stage left, then this new value for pan and tilt takes 
precedence over the previous value. This type of priority is known as latest 
takes precedence (LTP) because the latest change will affect the fixtures 
regardless of the value sent to it. LTP is generally used by automated lighting 
consoles for all parameters of fixtures. 

Some lighting consoles have an option of using highest takes precedence 
(HTP) for intensity parameters. In this case, the value closer to 255 will have 
priority over a lower value. For instance, suppose one playback or cuelist has 
an intensity of 80% (DMX value 205) and another has an intensity of 50% 
(DMX value 128). When using HTP, the first playback will have priority 
over the second and the fixture will remain at 80% because the first one played 
has a higher value than the second. Highest takes precedence is extremely use- 
ful to ensure that conventional channels are not accidentally blacked out or 
dimmed down by other playbacks or cuelists. HTP is generally used only for 
intensity channels, as most other parameters are not as clearly defined at speci- 
fic values (i.e., greater value = more output). 


TRACKING 


Most automated lighting consoles use a process called tracking. To a seasoned 
programmer, tracking is an essential tool. However, for those without a com- 
plete understanding of tracking, it often works against them. 


Nontracking Consoles 


To better explain tracking, I will first describe how a nontracking console 
works. As an example, suppose I have a show with six fixtures and am building 
cue one. After the intensity is assigned to full, each fixture is moved to its 
desired position and the color is adjusted. Then this information is stored 
as cue 1. My console will save not only the changes I made to the fixtures 
(intensity, position, and color) but also all the other attribute settings for the 
fixtures. The cue contains data that tell my fixtures not only where to point 
and in which color, but also which gobo to project, which iris setting, and so 
on (see Figure 2.1). 

When building cue 2, simply move the fixtures to a new position; again, my 
console will record data for all parameters of the fixtures (see Figure 2.2). While 
building cue 2, I have to assign the same fixtures to the same settings as cue | or 
I will see unexpected changes when going to cue 2 (the color assigned in cue | 
will revert back to the console defaults in cue 2). 
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FIGURE 2.1 Nontracking console cue | example. 


FIGURE 2.2 Nontracking console cue 2 example. 


To avoid this problem, the programmer will usually copy cue | to cue 2, 
then make the needed changes to cue 2. This creates a problem when you 
want to change the color used in cues 1-6. You will have to edit all six cues 
because each cue has the same color information. This is where tracking 
saves the day. 


Tracking Consoles 


As stated previously, nontracking consoles store values for all parameters of all 
fixtures in each and every cue. A tracking console will only store the values of 
the parameters you have adjusted. In simple terms, tracking avoids redundant 
data in the cuelist. Using the same example, build cue | by assigning intensity, 
position, and color. When this information is stored as cue 1, my console will 
only save the changes made to the fixtures (see Figure 2.3). My cue contains 
only the intensity, position, and color settings and no other information. 

Now as cue 2 is being built, I again simply move the fixtures to a new posi- 
tion and save the changes (see Figure 2.4). All other settings for the fixture 
(color, iris, and so on) will track into cue 2 from the previous cue(s). 

If I want to change the color being used in cues 1-6, then I will only need to 
edit cue 1, as the color setting will track into the following cues. 
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FIGURE 2.4 Tracking console cue 2 example. 


Advantages of Tracking 


When working with one large cuelist or cue stack, tracking has many advan- 
tages. First, cue creation is very easy. If cue 2 only needs to move the fixtures 
to stage right, then this is the only information needed in cue 2. There is no need 
to copy the other parameter settings from cue |. Secondly, because the console 
is only storing the changes made to each cue, editing becomes much simpler. 
For example, if you have thirty cues in a row with the intensity of your fixtures 
at 100%, this intensity setting only needs to be stored in the first cue. All the 
subsequent cues can be written with no value for intensity. The 100% setting 
will track through all thirty cues until you change the intensity on cue 31 to 
0%. If you later decide to change the intensity level for cues 1-30 you will 
only need to edit cue 1, as the setting tracks through all the other cues. 

Another powerful advantage to tracking is the ability to build cues or chases 
that only affect certain parameters or fixtures. This is the magic that allows pro- 
grammers to assign to a bump button a cue that will strobe the fixtures without 
changing any other parameters. At any point in a show the bump button can be 
pressed to add strobing to the fixtures without changing any other parameter set- 
tings. On a nontracking console this would not be possible, as the cue assigned to 
the bump button would have to contain position, color, as well as strobe. 
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Disadvantages of Tracking 


As you have read, tracking is very beneficial; however, it can also be confusing 
and frustrating. To return to my earlier first example, when building cue | only 
the changes (intensity, position, and color) were recorded, not any color, iris, or 
other values. When creating the cue the fixture had no color, but this information 
was not recorded because no changes were made to the color parameter. Later, 
when running the show, when this cue is played back a color is mysteriously 
projected on stage. This can happen when another cuelist is played prior to 
my example cuelist. Because cue | had no data for the color parameter, the con- 
sole tracked the previous color setting into cue |. The solution to this problem is 
to edit cue | so it contains color data, telling the fixture to project no color in cue 
1. The same problem can occur in reverse, when another cue is playing as a new 
cue is built. If an active cuelist assigns the fixtures to red and a new cue is written 
with no color information stored, then the fixtures may or may not be red when 
the new cue is played back. If a different cue is played first, assigning your 
fixtures to green, then the green will track into this new cue. This is because 
your new cue will allow any previous color to track into it. 

In my example of thirty cues with the intensity at 100%, a different tracking 
problem could develop. If cues 1-15 are for one dance number and cues 
16-30 are for another and then you change the intensity in cue | to 85%, 
you have just changed the intensity level for two different portions of your 
show. A good programmer will ensure that when edits are made, they do not 
track into subsequent cues where the changes are not desired. In Chapter 5, 
I will describe a very useful tool to solve this type of error—the block cue. 


Practice Makes Perfect 


Tracking is often considered one of the hardest concepts for automated lighting 
programmers to grasp. The results of tracking are often bewildering to the 
novice, as the console appears to not play back what was recorded. With an 
understanding of tracking, a programmer can manipulate the features of most 
automated lighting consoles with ease. The best method to ensure your under- 
standing is practice, so fire up your console and practice programming with 
tracking. 

There are many fundamental concepts related to automated lighting 
programming. Each fixture and console may refer to these items using different 
terminology, but a good programmer will identify the similarities and easily 
adapt to the specific vocabulary. With a basic understanding of these ideas 
you are ready to learn the particulars of automated lighting programming. 
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There are many things that must be taken into consideration before you can 
begin programming. In many ways lighting programmers are similar to airline 
pilots. We are at the controls of very sophisticated equipment, often working to 
meet impossible deadlines, and usually not seen by the audience (passengers). 
Just as a pilot will not simply board a plane and take off, most automated light- 
ing programmers do not just walk up to a console and rig and begin entering 
cues into the desk. There is a certain amount of preparation that must be com- 
pleted prior to taking off and building cues. Once the cues are built, an efficient 
saving routine must be followed to ensure all the hard work is protected. 


FIXTURE SETUP 


Before the lighting rig is set up, you need to be sure to communicate a few 
things to the crew. Programming will proceed smoothly if the fixtures are all 
hanging in the same direction (where applicable). If you have a batten with 
six wash lights on it, you want to make sure all the fixtures are oriented in 
the same direction. If two of them are 180 degrees off from the others, then 
when you tilt them all together, four of them will move upstage and two will 
move downstage. In addition, as most fixtures use wheels to bring in colors 
and effects, if they are facing in different directions, these wheels will appear 
to be coming from different sides of the stage. The best method to ensure the 
fixtures are facing the same direction is to place them all with their LEDs or 
data cables pointing in the identical direction. 

We live in an age when software makes everything function. Fixture 
manufacturers continually upgrade their fixture software to make improvements 
and add features. If your fixtures have different versions of operating software, 
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then they might behave differently. For example, a hard edge or spot fixture 
might have an update to its software that allows the gobos to rotate at a 
faster rate. If two of your fixtures have an older version, then they will not 
match the rest of the rig. Asking the crew to ensure that all fixtures have the 
most current operating software before the rig is assembled will help reduce 
problems later on. 

Most fixtures have a method of inverting pan and/or tilt via dipswitches or 
menus. Likewise, most moving light consoles have the ability to assign these 
settings from the console. It is best to have the crew turn off all pan and tilt 
inverts at the fixtures and allow the console to perform this function. If the func- 
tion is assigned at the fixture, then this setting must be remembered if the fixture 
is ever taken down and replaced. If there is a general rule that all fixtures have 
pan and tilt settings set to off, then the chance of error is reduced. 

Have you ever sent a strike or shutdown command to a group of fixtures and 
found one that just would not respond? One manufacturer has a mode in their 
fixtures that causes them to ignore some DMX control channel commands. This 
means that you cannot shut down or strike lamps unless the fixture is set to 
listen to these instructions. Sometimes a fixture mode is used to provide a 
smoother dimming curve or better color mixing. Further modes cause fixtures 
to change color or gobo functions from scrolling to split abilities. It is very 
important for a programmer to understand the various modes in the fixtures 
of the current rig and to ask the crew to ensure that all fixtures are set to the 
same mode settings. 

Most current automated fixtures have an LED or LCD menu that allows 
users to set the DMX address as well as the various fixture modes. These are 
fairly easy to use as long as you can decipher the sometimes short names 
given to modes (usually four characters). Older fixtures utilize dipswitches 
that require a chart to understand the various settings. Refer to your fixture’s 
user manual for full details. The latest technology of Remote Device Manage- 
ment (RDM) allows you to query a fixture for its DMX address, modes, and 
other settings. Using RDM software, you can then easily change the mode 
directly via your console or laptop. With this functionality implemented directly 
on consoles, DMX address and fixture mode changes are very simple. Further 
out, we will see greater adoption of a new industry standard called Architecture 
for Control Networks (ACN) in both fixtures and consoles. When this occurs a 
fixture can automatically tell a console what mode it is in, or a console can tell a 
fixture exactly how to configure itself. Finally there will be some intelligent 
lighting between our lighting fixtures and consoles! 


THE CONSOLE 


As the programmer, you are responsible for the operation of your console. You 
should be aware of not only how the console functions, but also what is 
required for your production. For instance, if you are going to use the Society 
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of Motion Picture and Television Engineers (SMPTE) timecode, you will need 
to specify to the sound crew what type of connector is required for the console’s 
input. In addition, you need to be aware of the version of the software loaded in 
the desk. If you simply turn on the console and begin programming, you might 
find that the console’s fixture library does not contain the fixtures you need, or, 
even worse, you might run into some console bugs. Just as fixture manufac- 
turers are continually updating their software, so are the console manufacturers. 
I always go to the website of the console manufacturer and download the latest 
software as well as the list of changes and/or bug fixes. I then read all the 
documentation and determine whether upgrading will be beneficial. Many pro- 
grammers find a version of software they are comfortable with and do not 
upgrade beyond it until absolutely required. Remember that everyone on the 
show will be looking at you when something goes wrong with the console, 
so you should load the version of software you think is best. Good programmers 
carry with them the version of software they intend to use on the console and do 
not count on the lighting supplier to have the console preloaded with a particu- 
lar version. It is also good practice to not change console operating software 
during the run of a show unless absolutely necessary (for example, bug 
fixes). Wait until next season to upgrade and follow that old saying, “if it 
ain’t broke, don’t fix it.” 

When specifying the console, you should also specify what accessories you 
will need. Never assume that the lighting provider will supply a keyboard, 
trackball, monitors, and so on. If you intend to have external monitors to con- 
nect to the console, be sure to place them on the order. It is best if you can plug 
the console into an uninterruptible power supply (UPS) and have additional 
front of house (FOH) power for anything else you might need (laptops, cell 
phone chargers). In addition, make sure that nothing else gets plugged into 
the UPS except the console or other show-specific items. You do not want 
the LD’s coffeepot killing the power to the desk in the middle of programming. 
I like to label every power cable plugged in at FOH. This procedure helps to 
identify what can be unplugged in the event that items need to be swapped 
out (see Figure 3.1). 

The FOH area often becomes your home during the production period. 
I always ask for a comfortable chair or stool, as I do not want to sit on a 
road case for a week (or even | day). There is nothing worse than being uncom- 
fortable 14 hours a day. Other items you might need at FOH include external 
backup media such as CDs or flash drives, little lights, audio playback 
(jam box), and/or video equipment (see Table 3.1). 

Many productions require a backup console. Usually the console will be 
loaded with the final show files and will be standing by in case something 
happens to the main console. In some cases an A/B switch is used to toggle 
the DMX lines should the master console go down. Oftentimes the testing 
of the backup console gets put off until just before it is needed. On the day 
of load in, it is important to open the box of the backup and test to make 
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FIGURE 3.1 Labeling FOH power cables helps identify plugs and purpose. 


TABLE 3.1 Suggested Front of House Items 


Monitors Backup console Intercom Coffee pot/cooler 
with ice 
Keyboard Floppy disks, CDs, | Power (multiple Trash can 
or flash drive circuits) 
Mouse/trackball Little lights Production monitor(s) | Chair(s) and 
(for televised table(s) 


productions) 


UPS Audio/video Printer Barricades/security 
playback personnel 
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sure it can load and save a show. This way, if you ever need to change out, you 
know it is in working order. When presented with the need for full redundant 
tracking backups, be sure to test all Musical Instrument Digital Interface 
(MIDI) or Ethernet connections to ensure that the tracking is functioning 
properly prior to the programming period. 

Most consoles require a certain amount of setup before you can begin 
programming. It is important to prepare as much as you can before arriving 
at the show site. Once the LD provides a plot, you can usually begin to organize 
the show file for your console. This can be accomplished in a lighting 
shop using an actual console, or any place using an offline version of the 
console on your computer. Most consoles provide software that allows all the 
console functions from any standard computer. Either way, you will need 
a console or emulator to prepare the show file. 

When preparing a show file, some programmers utilize a “start show” that 
contains their common preferences, views, palettes/presets, and other important 
tools. By loading a file such as this, you can be assured that all your shows 
share a universal setup that you are familiar with. Other programmers prefer 
to start fresh for each show and set up the console according the needs of 
each production. 

The next step is to add the number and type of fixtures to your show. You 
may need to clarify with the LD or crew chief as to special fixture modes or 
options to ensure that you utilize the correct fixture libraries. At this point 
you will also want to configure views (pre-saved layouts of console windows), 
define the system architecture such as network nodes, SMPTE setting, or MIDI 
inputs, and arrange system settings to tailor your programming experience to 
your preferences. Most consoles have a user-preference setting window 
where you can modify options to suit your specific programming requirements. 


PREPARING THE PATCH 


One of the first things that must happen when preparing a show is patching the 
console. If the patch is incorrect, then the console will be unable to communi- 
cate properly with the fixtures. Most fixtures communicate via DMX-512, the 
universal lighting language. Within this network of data each fixture is assigned 
a DMX start address that must be entered into the console. Sometimes the fix- 
ture addressing will be determined prior to the patching; sometimes the patching 
will dictate the addressing. This will depend upon the size of the show, the crew 
chief, the LD, and the programmer. Before you begin patching you have to 
understand how DMX addressing works. 

Let’s say you have a rig of six hard edge fixtures and six wash fixtures. The 
hard edge fixtures each use 18 channels of DMX and the wash fixtures 16 each. 
This means you will be using a total of 204 DMX channels. You now need 
to determine the start address for each fixture. There are two ways to calculate 
this. One way is to sit down with a notepad and calculator and do the math. 
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The other method is to patch them into your console or its offline editor 
(see Table 3.2). I prefer to use the console method, as most consoles do not 
allow overlapping addresses (that is, they do not allow for mistakes that 
could be made with a paper and pen). Also, once the information is in the 
desk, you can print the patch and use the printout to address the fixtures 
correctly. 

If the desk is capable of outputting more than one universe of DMX, then 
fixtures can be placed on the different universes. For example, if you have 
fixtures on the truss and fixtures on the floor, you might want to run a separate 
data line to each location. You could then plug the truss fixtures into universe 
1 and the floor fixtures into universe 2. Since each universe is its own set of 
512 DMX channels, you can address your fixtures within their own unique 
universe. So you might have two fixtures with the same DMX address, but 
on different universes. Of course, if you have a large number of fixtures in 
your rig, then you will have to make use of the different universes. 

It does not take long to utilize all 512 channels, as most modern fixtures use 
16 to 40 DMX channels. If your fixtures use 20 DMX channels each, you can 
only patch 25 fixtures per universe (20 x 25 = 500). When determining the 
patch, you will want to make sure that the point at which you change universes 
is a logical one. For instance, let’s say you have a front truss and a back truss 
each with 15 fixtures using 20 channels each. You would not want to put 


TABLE 3.2 Sample DMX Patch 


User Number Fixture Type DMx Starting Address 
1 Hard edge 1 
2 Hard edge 19 
3 Hard edge 3 
4 Hard edge 55 
5 Hard edge 73 
6 Hard edge 91 

11 Wash 109 

12 Wash 125 

13 Wash 141 

14 Wash 157 

15 Wash 173 


16 Wash 189 
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25 fixtures on one universe and 5 on the other, as one of the trusses would 
require two separate data runs (one for each universe). You would be better 
off to patch 15 fixtures to each universe and run one data line to each truss. 


NUMBERS EVERYWHERE 


Depending upon your desk, you might have a host of numbers assigned to your 
fixtures. Most consoles allow the programmer to define the handle for the fixture. 
The handle or user number is the number the programmer uses to select and pro- 
gram the fixture. This number is usually different than the actual DMX address of 
the fixture. This is because you generally want to number the fixtures in a linear 
order. In addition, you might choose to number them in a method that makes 
selecting them quicker and easier. One example would be to number the fixtures 
on the downstage truss 1-6 and the fixtures on the upstage truss 11-16. This way 
the user number reminds you of the placement of the fixture (downstage fixtures 
are less than 10 and upstage fixtures are greater than 11). Some programmers like 
to number according to fixture location, others according to fixture type. You 
might make the hard edge fixtures 21-28 and the wash fixtures 31-42. Another 
trick of the trade is to begin each sequence of numbering with the digit 1. For 
example, if I have 48 fixtures with 8 on each of 5 trusses, I might number 
them as 1-8, 11-18, 21-28, 31-38, and 41-48. You will notice I am not using 
the digits 10, 20, 30, and 40. 

Most programmers find it easier to remember which fixture is which if they 
begin the numbering at 11, 21, 31, and 41. This is because we can look at any of 
the five trusses and quickly determine the first, second, third, fourth, etc. fixture. 
If we had to deal with a zero, it would be more confusing to glance at a piece of 
truss and select the fifth light from stage right. 

Once all the user numbers are assigned and the fixtures are addressed, 
then the DMX addresses in the patch can be forgotten. As the programmer, 
you will only be working with the fixtures via their assigned handles. 
These numbers should be given to the LD and the crew so that everyone 
will refer to the fixtures with the same numbers. If you have a problem 
with fixture 85, you want the crew to know exactly which light you are talk- 
ing about. When drawing a plot, you should put both the handles and the 
DMxX address on the plot so that everyone can glance at the plot for the infor- 
mation they need (see Figure 3.2). 

When working with an LD, it is important to decide who determines the 
handle numbering. Some LDs will dictate what the numbers will be, but 
most will allow the programmer to make this determination. In this case the pro- 
grammer will need to notify the LD of the numbers that have been assigned. 
The LD can then enter these into the plot and paperwork and use the numbers 
when calling out cue data to the programmer. 

After the patch is complete, it is time to test. If the fixtures are set up incor- 
rectly, then the response from them will be incorrect, erratic, or nonexistent. 
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FIGURE 3.2 An example of a plot showing fixture numbering and DMX addressing. 


Once the entire rig appears to work, you need to check each fixture to ensure it 
is set to the correct address. If you simply select all fixtures at 100% to confirm 
they are working, you may not know that two of them have the same address. It 
is imperative that you cycle through each fixture one at a time to confirm that 
they are responding to the correct user number and DMX address you have 
assigned in your patch. You might also cycle through all the gobos to make 
sure all fixtures have the correct patterns in the same slots (especially if the 
LD has requested custom patterns). 


GROUPS 


Automated lighting consoles are filled with unique features for their program- 
mers. Most of these features are there to assist in the programming and organi- 
zation of a show. Some consoles have exclusive features unavailable in other 
desks, but all consoles share many of the same principles and features as 
well. One feature that is commonly found on automated lighting consoles is 
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called groups. This relatively simple concept is proving more and more 
valuable as shows become filled with more and more fixtures. 


Grouping Basics 


A group is basically just a reference to a fixture selection. For instance, one 
group may contain fixtures 1-12 while another contains 31-64. When a 
group is selected, it will recall the fixture numbers stored within and activate 
them for programming. The group function is merely a quick method to recall 
a specific, predefined selection of fixtures. Once a cue or playback is created, 
the reference to the group is lost and only the fixtures and their data are stored. 
If the cue is edited later, the programmer must reselect the groups used to build 
the cue (if he or she remembers). 

Groups are great for the organization of your show as they allow you to 
label various selections of fixtures for quick recall. Because the fixture numbers 
are not actually “stored” within a group but are instead recalled by a group, you 
can have multiple groups referencing the same fixture numbers. For example, 
you can have fixtures 1-12 in one group, 2, 4, 6, 8, 10, 12 in another and 1, 
3, 5, 7, 9, 11 in yet another. You can then label these groups appropriately, 
like “All Front Truss Wash,” “Even Front Truss Wash,” and “Odd Front 
Truss Wash.” Now if the LD asks you to select all the front truss wash fixtures, 
point them at center stage, and make half red and half blue, you can accomplish 
this task quickly by using your groups. 


Too Many Numbers 


Groups are a wonderful tool that, when properly set up, can greatly reduce the 
amount of time a programmer spends looking for fixture numbers. Typically, 
the console will provide the auto-generation of common groups by fixture 
type. When this feature is used, the desk will create an All, Odd, and Even 
fixture group based on fixture type. When completed, the result is usually auto- 
matically labeled and organized for you. Furthermore, some consoles will split 
fixture groups up further than just odd/even; they will separate by thirds, 
fourths, or more. This provides the programmer with a great starting set of 
groups, but there are always more to make. 

The auto-generated groups by fixture type are useful, but they are not 
specific to the show you are working on. For instance, all your wash lights 
may be in one group, but you probably also want groups that select them 
based on location within your rig. You will need to build custom groups that 
break the selections down by location and then label them accordingly. Some 
consoles with built-in fixture plot features can also auto-generate groups 
based on location, but most consoles are not this sophisticated. It is up to the 
programmer to look at the plot or rig and determine how to best create groups 
to be used in programming. Furthermore, you may wish to build groups based 
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on intended fixture usage within the show. If you have 24 hard edge fixtures 
and you know that numbers 421, 434, 465, and 472 are to be designated for 
the drum special, then you may want to create a group that contains these fix- 
tures. Additionally, you probably want to exclude these fixtures from your other 
groups of hard edge fixtures so that they are not accidentally selected. 

When preparing your show file, you should sit down with the plot and the 
concepts for the show and define what groups may be useful during programming. 
Remember that if you are working with an LD who will call out the programming 
to you, then the LD will want to help define and number the groups. I often create 
many groups based on fixture types, locations, uses, and more. I always label them 
clearly so I can quickly understand their intended purpose. 


Selecting with Groups 


Once groups are built, then you should get into the practice of using them to 
select your fixtures quickly. I like to reserve the first nine groups as my main 
selections by fixture type. The first nine groups are single digit group numbers, 
which means I can select them quickly from the command line of my console 
using a few keystrokes. I also personally always have group nine be my “All 
Moving Fixtures” group. In this manner I can quickly select this group to create 
a blackout or block cue. 

During my programming sessions, I will often use groups to help select 
complex combinations of fixtures. When the LD asks for all of the front 
truss in green, the back truss hard edge in red, the floor fixtures in blue/white, 
and the strobes at 50%, I know that I can select these groups as he or she is 
speaking and build the look without memorizing and typing in fixture numbers. 
This helps the programming session move along very quickly and ensures I do 
not forget some fixtures. However, I also need to be careful to not solely depend 
upon the groups for selections. If the LD suddenly asks for the third fixture on 
the mid truss to point at the cyc, I had better know its fixture number or have a 
method to look it up quickly. 


Additional Group Features 


The main purpose of groups is very straightforward. However, groups usually 
have even more power within them. Most automated lighting consoles not only 
store the fixture numbers within a group, but also retain the order of fixture 
selection. For example, imagine that I select fixtures as 2, 5, 3, 1, 4, 6 and 
store this as a group. Now when I recall this group, the desk will select fixtures 
1-6, but it will also remember the order in which I had previously selected 
them. This order can be seen when I then use the Next key to cycle through 
the selection or when I make use of Fan/Align features. I often will store various 
groups specifically to remember the order of fixture selection. This is very use- 
ful when making random selections, or when the fixture numbering does not 
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line up in a symmetrical method with the rig. For instance, let’s say you have 
four upstage vertical trusses with four fixtures down the front of each. You 
probably want a group that has each truss with the fixtures in order down 
each truss. However, you probably also need four groups that each have the fix- 
tures going horizontally across the four trusses. 

Automated lighting consoles also provide cool shortcuts to combine or 
merge groups, or even select the intersection between two groups. The intersec- 
tion feature allows the programmer to choose two groups, then the desk will 
only select the fixtures that exist within both groups. This is very useful 
when working with conventionals or other large numbers of fixtures. 


Read All About It 


The group feature of most consoles may seem very straightforward, but with 
practice you can improve your programming and organization through the 
use of groups. Every console has slightly different methods and features related 
to groups, so it is important for you to read your console’s documentation to 
ensure you are getting the most out of its grouping abilities. In the future, con- 
soles may retain more information about how a cue was built, and “embedded 
groups” may become the norm. Until then, groups will remain a simple but 
powerful selection tool to aid in all types of programming. 


BUILDING A BASIC OUTLINE 


When preparing a show file for an upcoming production, it is helpful to create a 
basic “outline” of the show elements that will be required. For instance, if work- 
ing on a concert tour, you can easily create pages and name them with the songs 
from the band’s albums. You might even start a blank cuelist for each page with 
the name of the song as well. This way, when you arrive on site, you are ready 
to begin building cues and do not have to waste the LD’s time as you enter in 
the song names. If working in theatre or on a corporate event you can easily find 
other elements of the show that require segmentation within your show file. 

Furthermore, you can also create position and color palettes/presets (see 
Chapter 4). When preparing a show, I will create many position palettes with 
my fixtures at 50/50, but name them all differently according to how I plan to 
use them. Then when I arrive on site I can easily update the palettes and remember 
what positions I had pre-planned to make. The same can be done with color mixing 
or color scrollers as well as with gobos, lens focus, and any other parameter. 


PROTECTING YOUR WORK 


As a moving light programmer, it is your duty to safeguard the lighting console 
data. I have seen consoles crash, show files become corrupt, floppy and hard 
disks fail, and even intentional sabotage. Lighting programmers must ensure 
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that the data they create is protected so that the lighting of the show is not lost or 
damaged. Saving should happen from the moment the console preparation 
begins until after the final performance. 

When you are hired to program a show, you are not just responsible for the 
entry of the data into the console, but also for the protection of that data. If data 
is lost due to console crashes, storage media failure, or operator error, it is up to 
the programmer to reenter all lost data. This can lead to a tremendous loss of 
time and creative energy. Of course, there are the rare instances where a cue 
can be built better the second time around, but usually you want to avoid having 
to rebuild cues. Lack of proper saving can add up to thousands of dollars for the 
producers. If reprogramming is required, someone has to pay the bills. This is 
one of the quickest ways to not get rehired. 

The many consoles on the market use just a few methods of storing their 
data. Older controllers might use a random access memory (RAM) card, 
while newer consoles use hard drives, flash drives, Zip disks, and even compact 
disc-rewritables (CDRWs) (see Figure 3.3). No matter the media, it is important 
to remember that all storage devices can fail at some point. Whichever media 


FIGURE 3.3 Various forms of media used for show storage and backup. 
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your console uses, you should always make multiple backups on various types 
of media. Even if your console has a hard drive and can make regular saves in 
the background, it is highly advised that you archive your work on other 
devices (floppy disk, CD, flash drive). 

It is very important to design a saving regimen that works for you and your 
console and to stick to it so it becomes habit. For example, when I am program- 
ming a show, I will save my work on the native storage (hard drive or disk) as 
well as make backups onto additional external media. I then make off-site 
copies daily so I can refer back to any day’s work. 

Let’s say the worst thing happens—your console crashes and erases 
everything since your last save. This could mean that you have lost hours of 
work, unless you are diligent about saving often. For instance, suppose you 
are working on a concert tour and you decide to save as you finish program- 
ming each song. If each song averages 3 hours of programming, then you 
will be in big trouble when data is lost. If you instead save several times 
during the 3-hour period, then you will not feel so depressed when something 
goes wrong. Sometimes it can be difficult to follow this regimen, as you and the 
LD will get into a rhythm and want to keep pressing forward. The longer you 
proceed without saving, however, the more you are living on the edge. Try to 
force yourself to save often (especially after creating a long sequence that was 
difficult to program). It is much better to wait a few minutes for the backup than 
to have to start over from scratch. Another rule I follow is to never walk away 
from a console without first backing up the show on external media. Whether 
I am going to the restroom or just up on stage for a moment, I will save my 
work first to ensure that nothing occurs while I am away from the desk. 

Now that you see the importance of saving often, there are more guidelines 
to follow. No matter the storage media, it is important to save to different files 
or disks. If you save often but always to the same piece of media or the same 
file on your hard drive, then you are still living dangerously. What if that file or 
flash drive becomes corrupted or fails? Then even though you have diligently 
saved, your work could still be lost. 

When working with older consoles that save directly to floppy disks, I suggest 
the following “leapfrog” method of saving your show (see Figure 3.4). Start with 
three to five disks and label these A, B, C, D, and E. Stack them in alphabetical 
order. Each time you save, take the disk from the top of the stack and save your 
show. Then on the next save remove the current disk and place it on the bottom of 
the pile. This way if something happens, you have two to four previous copies 
to refer to. 

When working with a console that uses a hard drive for storage, you should 
periodically save to different files on the hard drive. Try to name the file so you 
do not get confused as to which file is the latest (although you can usually read 
the time and date stamp of the saved file). For example, you might save your 
show files as “myshowA,” “myshowB,” “myshowC,” and so on. Also, it is a 
good idea to make periodic archives to another form of media besides the 
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FIGURE 3.4 The “leapfrog” method of data storage. 


hard drive in the event of a hard drive failure. Typically, this can be accom- 
plished by burning a CD, saving to a flash drive, or saving directly to another 
console or laptop via the console network. I cannot stress enough how impor- 
tant backup copies of the main show file are to a production. Never should you 
solely rely on a single file on the console’s hard drive. 

Once you have completed your programming session each day, it is very 
important to make and store multiple copies of your current show file. If you 
simply save it on the console and come back the next day, then what happens if 
the console lost your show file (or the console is missing, or some other 
problem)? I usually make two copies for myself (and keep my last two disks in 
the leapfrog set as well). In addition, I will make a copy for the LD and a copy 
for the crew chief. By distributing multiple copies of the show, I have ensured 
that should something happen to me (if I walk though a highly magnetic zone, 
am hit by a truck, etc.) then someone else will still have a copy of the show 
data. Also, I will copy the show file onto my laptop when I return to my hotel 
room (or on site if I have my laptop with me at the console). Making a separate 
folder on your computer for each day’s work ensures you always have an older 
copy of the show to refer back to. Once the show is complete, you can delete all 
but the final show from your computer (unless you like to hang on to all that data). 
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Many programmers use even stricter methods of protecting their work. 
Think of your saving method as insurance. Spend as much time saving as 
you feel you can afford. Keep in mind that the more you spend, the more 
you will be protected in the event of a catastrophe (but you do not want to 
spend all your time waiting for the desk to write to disk). I would not suggest 
saving after each cue is built, but I have seen programmers who save nearly as 
often. Some people will back up their show thirty times a day, while others will 
save their data only five times during a production’s run. The most important 
choice is to find a saving method that works for you and to use it consistently. 


ALWAYS BE PREPARED 


Each new production you program will present its own unique challenges. This 
is one of the reasons that working as an automated lighting programmer can be 
so much fun. Proper preparation for each new endeavor will allow you the 
freedom and peace of mind to concentrate on making the current production 
the best it can be. From ensuring the fixtures are operating correctly to setting 
up the console in an efficient manner, every bit of preparation will undoubtedly 
help the show. Many moving light consoles will allow you to import your 
common palettes and setups to make some of the initial setup even easier. 

In the future, when DMX is replaced by a network friendly protocol, each 
fixture might tell the desk what line it is plugged into and what its functions are. 
Then the programmer will only need to assign a user number to the fixture and 
begin programming. Some manufacturers have already incorporated this 
functionality using RDM and have consoles that can remotely address the fix- 
tures according to the patch in the desk. However, for the foreseeable future 
programmers will have to patch their fixtures into the desk by hand as part 
of their normal preparations for a show. 

By preparing for each production with proper planning for the front of 
house, fixtures, console setup, patch, and groupings, you can begin concentrat- 
ing on your programming sooner. As your preparations become habit, you will 
find it a simple process to specify what is needed as well as to prebuild or 
import data into the console. Much of programming is about consistency, and 
a consistent setup procedure helps produce an efficient programming 
experience. 
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Programming automated lights is essentially the data entry of specialized 
instructions into a custom computer application. This data is then transmitted 
via a standardized protocol to robotic lighting fixtures. While this appears to 
be a simple process, there is much more involved than simple data entry. An 
automated lighting programmer must be familiar with the particulars of the 
lighting console, the fixtures, the production, and the lighting designer. With 
a basic understanding of each of these elements, a programmer is able to 
properly create the lighting programming required for any production. 


UNDERSTANDING YOUR FIXTURES 


I can get inside my car and drive it to the airport; then I can get inside a rental 
car at my destination and drive it with ease. The steering wheel, gas and brake 
pedals are all in the same location and have the same functions as in all other 
cars. In Australia I drove a right-hand drive car and had to learn the differences, 
but the elements still worked the same (steering, braking). Moving light 
programming generally is not as easy as driving a car. This is because there 
are no standards when it comes to how fixture parameters should respond to 
DMx. 

Imagine if to steer one car you just use the steering wheel, but in another 
type of car you had to turn a knob to adjust the steering wheel mode between 
turning mode, straight mode, and skid mode, and in yet another type of car you 
had to turn the steering wheel, adjust the knob, and press on a pedal to adjust the 
speed of the turning. It would be very difficult to adjust from one vehicle to 
another without first studying the method of steering. This is the case with 
many automated lighting functions! 

Many hard edge automated fixtures have rotating gobos. The number of 
DMxX channels used to select and rotate a single gobo can range from | to 5 
depending on fixture type and DMX mode. Because of all the differences, 
most lighting consoles simply apply the DMX protocols of the fixtures to 
adjustable parameters. This can lead to much confusion when programming, 
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as it requires that the programmer be familiar with the particularities of each 
fixture’s protocol. 

It is imperative that you study the DMX protocol of each fixture type within 
your lighting rig so you understand the capabilities and functions of that parti- 
cular unit. Without this basic understanding, you will spend most of your time 
trying to figure out how to “drive” each fixture. Just because you know how to 
rotate gobos with one type of fixture does not mean you can do the same with 
others. Prior to beginning programming, you should read the DMX protocol of 
each light and then test its functions. I suggest downloading the manuals and 
protocols of the fixtures before you even arrive at the production site. In addi- 
tion, you can use most consoles’ offline editors to determine exactly how the 
fixtures are implemented into the console. 

Although every fixture is different, there are some common guidelines as to 
how most professional automated lighting fixtures function. Below I have listed 
the common parameters and their usual functions. Please be aware that both 
console and fixture manuals might refer to these items with different 
terminology. 


Pan and tilt: Controls the movement of a mirror or moving head. Typically, 
two channels are used for each parameter to create 16-bit accuracy. 
Intensity: Usually 0-100% controls the output of the fixture. Note: Some 
manufacturers place additional parameters on this channel, such as strobe 
or control. 

Color mixing: Cyan, magenta, and yellow are variably controlled via 0-100%, 
with zero equal to no color and 100% full color. Some fixtures are reversed or 
will contain additional fixed colors on the same control channel. 

Fixed color: Certain values on this channel recall specific colors from a 
color wheel. Other values may recall half or split colors. In addition, 
there are usually pre-made spins of the color wheel at different speeds to 
select from this channel. 

Frost: 0-100% provides variable control of a frosting or softening of the 
output. Usually, zero is equal to no frost and 100% full frost; however, 
some fixtures are reversed or may contain additional frost strobing effects. 
Shutter strobe: This channel controls the shutter of the fixture. The shutter 
will normally be open, with an option for closed. In addition, various types 
and speeds of strobing are available. Some manufacturers also place control 
functions on this channel. 

Control: The control channel often contains all nonstandard programming 
functions. Lamp on/off, fixture shutdown, fixture reset or home, and other 
specific functions are accessed from this channel. Usually a modifier (strobe 
channel closed) and/or a time value (hold at a value for 5 seconds) is 
required to prevent accidental triggering of control functions. 

Fixed gobo: Certain values on this channel recall specific gobos from 
a nonrotating gobo wheel. Other values may recall half or partial gobos. 
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In addition, there are usually pre-made spins and/or shakes of the gobo 
wheel at different speeds to select from this channel. 

Rotating gobo: Certain values on this channel recall specific rotating gobos 
from a rotating gobo wheel. Other values may recall half or partial gobos. In 
addition, there are usually pre-made spins and/or shakes of the gobo wheel 
at different speeds to select from this channel. 

Rotate speed: Most manufacturers use an additional channel to adjust the 
speed of rotation for the rotating gobo wheel. Depending on the fixture, 
this channel might also select the mode (indexing, rotate forward or reverse) 
of the rotating gobo. 

Iris: This channel adjusts the iris of the fixture from a small size to full open 
(or vice versa) when adjusted from 0 to 100%. In addition, the channel 
might include premade iris strobing and effects. 

Speed: Many fixtures include speed channels to allow for fixture control 
crossfades of values. This functionality is used to create smoother transitions 
than is possible by most DMX controllers. See the following for further 
information on speed channels. 

Mode channels: Sometimes manufacturers will add mode channels to their 
fixtures. These channels are used to modify the functionality of another 
channel. For example, a color mode channel will change the behavior of 
the protocol for the fixed color wheel. The normal mode for the color 
wheel might be to select fixed colors as the value changes from 0 to 
100%. If a different mode is selected from the color mode channel, it 
will change the fixed color channel so it will spin at various speeds from 
0 to 100%. Yet another mode might spin the wheel in the opposite direc- 
tion, or allow for oscillating between two colors at different speeds. 
Mode channels are commonly found for color wheels, gobo wheels, and 
rotating gobos. 


There are many more parameter types depending upon your fixture type. Refer 
to the fixture’s DMX protocol documentation for exact details on all para- 
meters. If you are unsure as to how a particular function is controlled from 
your lighting console, it is best to experiment with some test cues. 


SPEED CHANNELS 


DMxX < is a simple protocol that was developed to control lighting dimmers. 
As automated lighting developed, it latched onto this protocol as a uniform 
standard for lighting control. However, the resolution offered by 256 values 
per channel is rather limiting. Most manufacturers found they needed a higher 
resolution for pan and tilt. By combining two DMX channels to control a single 
parameter, they are able to achieve 65,535 values per parameter. This is referred 
to as 16-bit DMX control, and it is commonly used for pan and tilt as well as 
rotating gobo indexing. 
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With very slow movements of fixture parameters, 256 or even 65,535 values 
are not enough. If you have ever tried to move a parameter extremely slowly 
(2 minutes or more), then you have probably noticed a shaky or steppy movement. 
This is because the resolution of DMX crossfading is less than adequate in these 
situations. For this reason most manufacturers of automated lighting have provided 
a timing parameter to achieve higher resolution movements. Now instead of step- 
ping between a value of 10 and 22 across 2 minutes via a DMX crossfade, you can 
tell the fixture to move from one position to another in 2 minutes smoothly. The 
console instantly sends the new value and speed timing to the fixture, and the fix- 
ture moves the parameter at the selected time with a much higher resolution than 
can be achieved via DMX. This usually results in smoother parameter movements. 

So how do you use these magic-timing parameters? Well, that really depends 
upon your fixture, so it is back to reading the DMX protocol for you. First, how- 
ever, you need to know what to look for, as each manufacturer uses different names 
and types of speed controls. Some of the names are Mspeed, Vector Speed, Beam 
Time, Focus Time, Color Time, Speed, Vector, and Xfade. The names might be 
different, but there are some similarities in programming these timing functions. 

The first rule is that if you are not going to use the timing functions, ensure 
that you have the channel(s) set to their off setting. This is not the same as the 
fastest speed setting, but a different value that disables the internal timing of the 
fixture altogether. The speed controls of fixtures are often broken down by type 
of parameter (beam, color, pan/tilt). On the other hand, some manufacturers 
provide one universal speed parameter and then allow the programmer to select 
which parameter will be affected by the speed channel. For example, the DMX 
protocol of the channel used for gobo selection might have all six gobos in 
crossfade mode and then all six gobos in speed mode (see Table 4.1). 

Selecting gobo 2 from either section of the protocol will yield the same image 
on stage; however, the speed mode version will respond to the speed channel tim- 
ing. When selected with speed timing on, the gobos will scroll into their position 
in a time defined by the speed channel. Without this setting the gobos will either 
jump directly to their new setting or follow the console’s crossfade time. Always 
refer to the user’s manual to see how specific fixtures function. 

If the desired effect is to change from one gobo to another in 2 minutes, 
you would select gobo 2 (possibly in speed mode), then set the speed channel 
(possibly the beam speed) to 2 minutes. Now you must ensure that your console 
does not try to crossfade the value for the gobo channel or the speed channel. 
The best thing to do is to assign the gobo channel and the speed channel a cross- 
fade time of zero (or set the entire cue time to zero). If you were to crossfade 
either of these two parameters, you would confuse the fixture, as it would try to 
calculate the movement speed while the desk is crossfading. The result would 
be a movement much slower than you intended. 

To avoid having a separate speed channel for each parameter of the fixture, 
the manufacturers have given us either one speed channel or several categorized 
speed channels. This means that when you assign a gobo to change in 2 minutes, 
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TABLE 4.1 Sample Gobo Channel DMX Protocol 


DMxX Channel DMX Value Effect 
8 Gobo 0-10 Open 
11-30 Gobo 1 
31-40 Gobo 2 
41-60 Gobo 3 
61-80 Gobo 4 
81-100 Gobo 5 
101-120 Gobo 1 speed controlled 
121-140 Gobo 2 speed controlled 
141-160 Gobo 3 speed controlled 
161-180 Gobo 4 speed controlled 
181-200 Gobo 5 speed controlled 
201-240 Gobo spin varied speeds 
241-255 Open 


this might also affect other beam parameters or even pan and tilt. This is a situa- 
tion where you need to study the manual again to determine what options you 
have. Some fixtures have options on controls or other channels to disable speed 
functions from pan, tilt, and so on. In addition, with tracking consoles you need 
to be aware of when you have turned on the speed channel. You might need to 
turn it off for the next cue. If you forget to turn it off, then it will remain on for 
the rest of your show and possibly wreak havoc with all your future crossfades. 
In addition, if you try to manually move the fixture or its parameters, it might 
take 2 minutes to change from one gobo to the next. 

Timing and speed parameters are not used with every cue, but they are a 
handy tool that allows for smooth, slow transitions and changing of parameters 
that might not be crossfadable. It is extremely important that you study your 
fixture’s DMX protocol to determine exactly how these speed functions relate. 
Each manufacturer has its own methods, and often these can change between 
fixtures. Then be sure not to crossfade and use speed channels at the same 
time. Finally, ensure you disable the speed functions when they are not needed. 
These powerful functions are often misunderstood and underused; however, 
with a little reading and practice, they can be easily mastered. 


CONVENTIONAL CHANNELS 


There comes a time when an automated lighting programmer will have to patch 
in and program conventional lights. Par cans, ellipsoidals, fresnels, and basi- 
cally any light that does not move are considered conventional lights. When 
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working with these fixtures on an automated lighting console, there are many 
important factors to consider. A programmer must decide on a patching method 
as well as a numbering scheme. Additional accessories such as scrollers, 
strobes, and DMX-triggered foggers often function in similar methods as 
conventionals. 

When patching conventional fixtures into an automated lighting console, 
there are basically two processes. In the first scheme, the lighting programmer 
will simply assign a fixture number to each DMX-controlled dimmer. For 
example, if the lighting rig consists of 96 dimmers, then 96 single channel fix- 
tures will be added to the show. When patching, each of these single-channel 
fixtures (sometimes called desk channels) will be mapped to individual DMX 
addresses that control a single dimmer. Although the dimmer might be con- 
nected to one or more fixtures, it is added to the console as a single fixture. 

The programmer must then build groups on the automated lighting console 
in the same manner as building groups with automated fixtures. Conventional 
dimmers connected to lights focused on the same stage area or using the 
same color will often be recorded into the same group. This allows for quick 
selection of all “red backlight” channels in a single selection. This method 
increases the total number of fixture numbers within the show, but provides 
greater flexibility by allowing multiple combinations of conventionals to be 
assigned to various groups. 

A second method of patching conventionals is to “soft-patch” multiple dim- 
mers into a single desk channel. For example, 96 dimmers might be patched 
into 12 discrete desk channels. Channel 1 might control 20 dimmers of “red 
backlight.” This method reduces the number of fixture numbers within the 
show, but does not allow for selection of individual dimmers. Both methods 
have their own sets of pros and cons. The first method of building groups 
makes it simple to add or change dimmers to a group. However, any cues 
that have been previously built with a group will not reflect changes to the 
group. For example, suppose the “green wash” group contains fixture numbers 
1, 4, and 7 and cues are built with this group of fixture numbers at full. Then it 
is discovered that desk channel 9 should be added to the group. Adding the new 
fixture number to the group will affect all new cues, but the change will not be 
reflected in existing cues. 

The second method solves this problem by using fewer fixture numbers and 
“erouping” dimmers in the patch. If additional dimmers are added or removed 
from the fixture number in the patch, then programming information in pre- 
viously written cues for that fixture number will instantly reflect the changes 
made in the patch. Using the previous example, fixture number 12 might 
equal the “green wash” with dimmers 1, 4, and 7 patched to it. If dimmer num- 
ber 9 is later patched to this channel, then all cues with values for user number 
12 will automatically include dimmer 9. The same problem also occurs if a fix- 
ture number needs to be removed from a group, as it will not be removed from 
previously written cues. 
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So why not always use the second technique? Well, with the second method, 
dimmers are locked to a particular fixture number and cannot be broken apart. If 
the “green wash” contains four dimmers and the LD asks for just dimmer num- 
ber 7 in cue 15, this would be impossible. With the grouping method, it is very 
simple to recall single dimmers from a group. The grouping system is much 
more flexible; however, it is not as friendly when changes need to be made. 
In the future, automated lighting consoles may contain “embedded groups,” 
where cues will remember which groups were used in their construction and 
then automatically update with any changes made to the group. Until that 
time programmers will need to decide on a show-by-show basis the best method 
of patching their conventional fixtures. 

The programming of conventional fixtures is fairly straightforward. Since 
there is a single attribute to adjust (intensity), they are much easier to program 
than automated fixtures. However, many lighting consoles provide unique fea- 
tures specifically tailored for conventional programming (and usually also 
applied to the intensity of automated fixtures). First is recording of time. 
When recording a cue, the time for conventional fixtures can usually be entered 
as a split time. A split time is actually two separate values split by a designator 
(usually /). The first time is the fade up time and the second time is the fade 
down time. This is extremely useful when the programmer is not aware of 
the previous values for the fixtures. For example, if all fixtures are assigned 
a value of 75% and recorded as cue 2 with a time of 5/10, then any fixtures 
increasing from cue | to 75% will do so in 5 seconds. Any fixtures decreasing 
from cue | to 75% will do so in 10 seconds. This syntax shortcut saves the pro- 
grammer from having to examine the previous cue and determine which lights 
are fading up and which are fading down. 

When an automated lighting programmer sits at a desk and begins patching 
conventional fixtures, there are several options to consider. The method of 
patching and various console functions must be taken into account. The 
LD is not going to tell the programmer which methods to use; instead, the 
LD will hand over a patch sheet and wait for the information to be input 
into the desk. The programmer must decide which process adapts best to 
the production at hand. When working with both automated and conventional 
fixtures on the same desk it is easy to become overwhelmed, especially during 
patching operations. A good programmer will utilize the conventional specific 
functions of the console to best optimize the programming and playback 
experience. 


PALETTES/PRESETS 


Once you have patched the console, created groups, and become familiar with 
your fixtures, you should begin building position, color, and other palettes. 
Depending upon your console, these might be referred to as palettes, presets, 
memories. These are references used to quickly select common parameter 
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data used when programming. The most commonly used palette type is for 
fixture postitions. Most programmers take the time to build position palettes 
that they feel will be used within the production. Once the positions are stored 
in the console, they are available for instantaneous recall, without having to 
move fixtures manually into position. In addition, if your cues refer to the 
palette (instead of pan and tilt values), then you can update the palette values 
and the cues will simultaneously update with the new information. This 
can be a lifesaver when the director decides to move an acting area upstage 
by 2 feet. You simply adjust the fixtures in that position palette, and all your 
cues referencing the palette will be corrected. Position palettes are commonly 
used in touring productions, as the lighting rig rarely hangs at the same height 
and location relative to the stage. Palettes allow for the updating of only a small 
number of positions instead of a large number of cues. 

First, look at the stage and try to determine common positions for the 
fixtures. If the show has a band with a singer, guitar player, bass player, and 
drummer, then these would be the obvious positions to build. It is best to 
focus every fixture in each of these common positions. That way, if the LD 
asks for fixture number 28 in the drummer position, you can quickly select 
the fixture and the position. Even if you are programming a one-off type 
show and do not plan on using the updating features of palettes, they will be 
extremely useful when building cues. By spending a few hours building posi- 
tion palettes, you can save many more hours when programming, as you do not 
need to move each fixture individually for each cue. The cue-building process is 
made simpler by allowing you to select very quickly the common positions for 
the fixtures (see Table 4.2). 


TABLE 4.2 Common Position Palettes 


Stage Areas Stage Washes House Areas Specials 
Downstage right 50/50 Audience Podium 
Downstage center Straight down Random audience Orchestra 


Downstage left 
Midstage right 
Midstage center 
Midstage left 
Upstage right 
Upstage center 


Upstage left 


Downstage edge 
Cyc or backdrop 
Stage wash 
Cross stage wash 
Random stage 


Floor wash 


Up and out 
Straight up 
Fan outs 
Blinders 


Venue walls 


Front of house 
Band positions 


Acting areas 
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In addition, building color and gobo palettes can produce the same benefits. 
In the same manner as building position palettes, most desks allow for the crea- 
tion of palettes with any parameter of the fixtures. Imagine having to continu- 
ously color mix the same shade of blue for each cue! A color palette allows for 
instantaneous selection of this color. Then if the LD or director of the show 
decides the blue is too pale and asks you to change all cues using that color 
of blue, you simply update the palette and not each and every cue. Once 
again, programming and editing will be accelerated due to the ease of palette 
selection and modification. For example, if the LD asks for “fixture number 19 
upstage center in red with the cone gobo,” you could achieve this in a few sim- 
ple keystrokes. 

Prior to building palettes, it is a good idea to home (or recalibrate/reset) your 
fixtures. If the fixtures are out of calibration when you build your palettes, then 
the palettes will be misaligned after the fixtures are recalibrated (or even 
powered on and off), causing you to have to touch up your palettes. 

Some other palettes you might want to consider building are iris, frost, 
intensity, and fixture homing or shutdown. The more palettes you premake, 
the less time you will spend in cue creation dialing through values. However, 
do not allow this preparation to get out of hand, as you do not want to spend 
all your time building palettes and groups. 

Quality is often better than quantity, so I suggest that you only create 
the groups and palettes that you think will be used with the production. The 
more palettes you have, the more that will need updating in the future. In 
addition, a large number of palettes can slow down your programming if you 
have to search through hundreds of palettes to find the desired position or 
color. A good programmer will discover the perfect amount of palettes for 
each situation. Some productions will require hundreds of palettes, while others 
only a few. Your ability to determine the essentials for each production while 
also maximizing the output potential of the fixtures will aid the LD’s overall 
process in creating a successful production. 


This page intentionally left blank 


Chapter 5 


Intermediate Programming 


Mark Cues 41 Adjusting Intensity Effects 52 
Tricks of the Trade 42 Use Effects Wisely 53 
Automated Mark Cues 43 Kickin’ It Old School 53 
The Magic of Marking 44 The Fireworks Chase 54 

Block Cues 44 Making the Magic 55 
Marking and Blocking 45 Timing 55 
Organization 46 Modern Miracles 56 
Overblocking 46 Applying Concepts 56 

Effects Generators 46 Common Chases 56 
The DMx Protocol 47 Fanning 58 
Trigonometry to the Rescue 47 The Origins of Fanning 58 
Modifying the Starting Point 47 Basic Fanning Procedures 58 
Modifying the Size and Rate 48 The Order of Fixture Selection 59 
Offsetting Each Fixture 49 But Wait! There’s More... 60 
Different Wave Forms 49 Now is the Time 60 
Other Parameters 50 Stay Cool as You Fan 61 

Intensity Effects 51 
Adding Dynamics 51 


Once an automated lighting programmer understands the basic concepts of 
programming consoles and fixtures, the skills beyond console syntax and 
DMX protocols must be learned. There are specific routines that programmers 
use daily, yet these skills are rarely detailed in manufacturers’ manuals. This 
chapter discusses these talents and describes why they are important. 


MARK CUES 


One of the most important elements of good programming is an excellent 
transition from cue to cue. If a show is programmed with no consideration as 
to how the fixtures change from cue to cue, then the programming can look 
sloppy. When you notice fixtures moving into place as they fade up or abrupt 
gobo changes, chances are these are unintended mistakes. The programmer 
probably did not take the time to preassign the fixtures in their new settings. 
An essential tool to prevent these mistakes is the mark cue or setup cue. 
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Some consoles either automate this process entirely or have tools to make it 
easier, while other consoles leave it to the programmers to build their own 
mark cues. Regardless of your console, it is important to understand how to 
build mark cues and what they are used for. 

The most common example for a mark cue begins with a simple transition of 
scenes in a theatrical show. If cue 5 has two fixtures fade out on stage right, then 
cue 6 has the same two fixtures fade up on stage left, you will see the need for mark 
cues. As the fixtures are fading up on stage left, they will also be moving from stage 
right to left. This is not the desired effect, as you only wanted to see them fade up in 
their new position. What you need is for the fixtures to move in black (MIB) to their 
new position. This will require a cue between cues 5 and 6 (5.5) that presets or 
marks the fixtures. Usually you will assign a time to cue 5.5 so that it will occur 
automatically once cue 5 is complete. This way, when you trigger cue 6, the 
fixtures will simply fade up already in their new position. Cue 5.5 would now 
be a mark or setup cue. 

Visually the mark cue does nothing, but in reality it is preparing the fixtures 
for their next cue. As soon as the blackout of the two fixtures finishes (cue 5), the 
mark cue is played (cue 5.5). It moves the fixtures into their new position while 
still in black. Then when the fade up cue is played (cue 6), the fixtures are 
already in position and simply fade up without moving. My example is with 
positions, but it can be applied to any attribute of the fixture. For example, 
let’s say you have a gobo wash on a cyclorama in cue 10, fade out in cue 11, 
then fade up again with a new gobo wash in cue 12. You will need to place a 
mark cue at 11.5 to change the gobo while the fixtures are in black. If you do 
not have a mark cue, then you will see the gobos change while the gobo 
wash is fading up in cue 12. 

Often the need for a mark cue is not known until the cues are played back. 
Only then do you notice that the fixtures are not preset for their next cue. When 
you replay your cues in rehearsal and notice fixtures moving into positions 
while fading up, you should note the cue numbers and create mark cues (unless 
the move is part of the desired effect). Then the next time your cuelist is played, 
the mistakes will no longer be a part of the show. 


Tricks of the Trade 


When building cues you need to think both forward and backward to determine 
where a fixture is coming from and where it is going. If you are aware of 
this while building cues, your programming will go quickly and cleanly. There 
will be no need to add mark cues after the first time playing back the cues. 
In the previous example, when building cue 12 with the new gobo wash, you 
can simply save a copy of this cue with intensity at zero for cue 11.5. This way 
you will have created the mark cue at the same time you created the original cue. 

Another good trick when building mark cues is to create an intensity palette 
with all fixtures at an intensity of zero. Next, label this palette “mark.” Now 
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every time you build a mark cue, instead of setting the intensity to zero, select 
this palette for the fixtures you wish to mark. The fixtures will be assigned an 
intensity of zero, but instead of indicating 0%, the console will display the 
palette name “mark” (assuming your desk has these functions). The data in 
your cue will indicate to you that those fixtures are being marked because 
the intensity channel will be labeled as such. If your desk allows for tracking, 
you can then look at the contents of a cue any time and see that the fixtures are 
marked. This will save confusion later on when adding cues, as you will be able 
to tell the difference between fixtures that simply have an intensity of zero and 
those that are marking (although both will actually have an intensity of zero). 

Many automated lighting programmers use unique numbering to help 
identify their mark cues. For instance, cue 20 might be followed by a mark 
cue at 20.05 and cue 22.2 by 22.25. This method places a 5 at the hundredths 
place digit of the cue number and allows for quick and easy identification of 
mark cues. In addition, if the console allows for naming of cues, the cue 
could be named “mark.” The most important factor to remember is to be con- 
sistent with your numbering and labeling so that all mark cues (and only mark 
cues) use the unique scheme. 

Once your mark cues are built, you must also consider the timing of the 
mark. If you are presetting fixtures in a new position with a mark cue, you 
need to ensure that the fixtures are in the new position before it is time for 
the fade up cue. If the mark cue does not have time to complete, then the 
fixtures will not be fully marked. On the other hand, some situations require 
slow marks. For example, if you have moving-head fixtures on the stage, 
you might not want them moving quickly into their new position, as it could 
be distracting. In this case you might assign a few seconds of crossfade to 
your mark cue so the fixtures move slowly into position (assuming you have 
enough time between cues). Also, when marking color scrollers, it is important 
to consider the speed at which the mark happens. If the mark occurs instantly 
and the scroll runs the entire length possible, it might be noisy. There is nothing 
worse than hearing a group of scrollers slam to a new color in the middle of a 
quiet scene. 


Automated Mark Cues 


Some consoles have powerful features that allow for automated creation of 
mark cues or move in black settings. These tools are very useful, as they will 
analyze your programming and determine when a fixture changes from an 
intensity of zero to an intensity above zero. If the console concludes that the 
fixture is changing attributes (position, color, gobo, etc.) between the two 
cues, then it will automatically set up or mark the fixture. This allows 
for very quick, almost lazy programming, as the desk will correct potential 
problems for you. However, most consoles with automated marks or move in 
black features do not give you total flexibility or labeling abilities. For example, 
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a mark cue might be inserted between cues 4 and 5, but there might not be data 
associated with this in the various views of the console. If you had built your 
own mark cue (and not used the automated one from the desk), you would 
have gained this powerful labeling tool. In addition, many of the automated 
marking functions do not give you complete control of the mark. If you have 
conventional fixtures with a gel scroller, you might want to mark the scroller 
change so the color change happens in black. Some desks do not associate 
the scroller with the dimmer channel and would miss this in their automated 
marking function. Furthermore, you may wish for the scrollers to mark in a 
different time than automated fixtures. Hopefully, your console’s auto-marking 
feature allows for individualized fade times within the mark cue. 

Making use of console-created auto-marks greatly increases productivity 
and speed of programming because the programmer does not have to think 
about where the fixtures are coming from. Many consoles have the ability to 
auto-mark an entire list, and thus all programming transitions will be “clean.” 
However, what happens when you wish to see a light move as it fades up? It 
is very important for you to understand the limitations and possibilities of 
your console’s mark functions. 


The Magic of Marking 


Mark cues assist in producing clean lighting transitions, while minimizing 
distractions to the audience. Shows programmed without regard to what occurs 
between cues appear sloppy and unprofessional. By taking the time to preset 
your fixtures, or to use console functions to assist in the process, you can dras- 
tically improve the quality of your lighting programming. However, keep in 
mind that not all transitions have to be clean. When planned within the cueing, 
it is often remarkable to see lights change parameters while fading up. This 
change adds another element of interest to the lighting cue. Ultimately, it is 
up to the designer to decide what type of effect is desired. Until technology 
allows the fixtures to read our minds and know what we are going to do 
next, mark cues and move in black features will be a vital part of automated 
lighting programming. 


BLOCK CUES 


Tracking records only the changes you make to each cue and allows previous 
values to remain unchanged or track into the current cue. There are, of course, 
times when you want to prevent values from tracking into your new cue, and 
this is where block cues come in. 

A block cue is defined as a cue that contains all parameters for a fixture or 
fixtures. The block cue will not allow any values to track into it from previous 
cues or cuelists (see Figure 5.1). This is especially important when you step 
back and break your show into sections. For example, when programming a 
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Tracking values ; New tracking values : 


Block cue 


FIGURE 5.1 A block cue stops the flow of tracking data. 


dance recital, suppose cues 1—27 are for the first dance number, 28—42 for the 
second, and 43-82 for the last dance number of Act I. It would be best to make 
cues 1, 28, and 43 block cues, so that no values could track into each individual 
dance number. If you do not build a block cue at the start of each section, then 
you run the risk of data flow problems. For instance, suppose cue 26 changes 
the wash lights to indigo. The wash lights do not change values again until cue 
40, when they change to red (the color values were not recorded into cues 
27-39, allowing the color to track). During the dress rehearsal, the LD decides 
to change the color of cue 26 to green. This change is perfect for the end of the 
first dance routine (cues 26 and 27), but now the green will also track into cues 
28-39, drastically changing the look of the second dance routine. Had cue 28 
been a block cue with the color value recorded as indigo, then the changes 
could have been made to the first routine without affecting the following routines. 

By strategically placing block cues into your show, subsections of program- 
ming can be created. A block cue can provide a fresh start, where you know no 
changes earlier on will affect future cues. Even in unstructured shows, carefully 
placed block cues can prove to be helpful. For example, if you are simply flying 
through looks on bump buttons for a one-off concert, most of your cues will 
probably allow certain attributes to track. You might have a button for a color 
chase, another for strobe, another for ballyhoos, and so on. It is good practice 
to have a look to go to that is fully blocked (maybe at the end of each song). 
This way when you play the blocked cue, you can be assured that all other 
chases, effects, etc. will not track into the look. Then from this blocked state, 
you can continue adding tracking cues to create new looks on stage. 


Marking and Blocking 


I once programmed an ice skating tour that was running via SMPTE timecode. 
I had to build the show to prepare for any skater not being able to skate on any 
given night due to injury or any other possible issue. The sound operator would 
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simply skip that portion of the audio track and the associated timecode, causing 
the lighting console to skip ahead in the cuelist to the beginning of the next 
number in the show. To prepare the show for these occasions, I had to be 
sure that my mark cues were also block cues as well as the start of timecode 
for each skating number. If I had simply allowed the console to jump from 
one skate number to another without blocking my mark cues, then who knows 
what kind of wacky looks would have been “created” by skipping portions of 
the show. Without the block cues in place, the data from the previously played 
skate routine could have tracked into the next routine. Blocking all values for 
your marked fixtures ensures that any unwanted tracking information doesn’t cor- 
rupt your final state on stage. 


Organization 


When building cues that are also blocked, make a point to note this in the 
cuelist. If the console has a comments field, I will usually indicate a blocking 
cue with “BLOCK.” This way, I can tell from a glance at the cuelist where 
I have broken the chain of tracking and how I have divided my show. As indi- 
cated earlier, the mark cue for the beginning of a number of a section of the 
production will usually also be the block cue. 


Overblocking 


There are, of course, times when blocking can be a hindrance. You would not 
want to block every single cue in the show, as this would totally eliminate the 
tracking. If you have a blocking cue in the middle of a dance number and you 
expected a certain fixture to track its gobo through all the cues, you must make 
sure the block cue does not destroy the tracking for this fixture. As every show 
is different, blocking needs will change from production to production. Just as 
with any tool we have in our programming bag, it is up to you to determine 
when to block and when to allow values to track. Understanding the value of 
each option can aid in making any show a success. 


EFFECTS GENERATORS 


Virtually all automated lighting consoles contain effect generators, which are 
mathematic routines used to automate fixture parameter changes. Mathematics 
is a subject that we all study in school, but generally we allow modern technol- 
ogy to assist us in the more complex algebraic and trigonometric functions of 
everyday life. Our lighting consoles perform a great deal of math with every 
function programmed into them, and usually we do not even think about 
how the consoles operate. However, by understanding the basic principles 
involved, we can better use the applications to achieve our end goal on stage. 
Most automated lighting consoles now come with some sort of effects generator. 
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Each of these systems might appear different, but underneath they all operate on 
the same principle: math! That’s right. The console’s automatic effects are 
composed of simple trigonometry formulas such as y = a sin[b(x — c)] + d and 
sin(x) * cos(3 * x) * pi/2. 

While Hipparchus (190 B.c.—120 B.c.), known as the father of trigonometry, 
might have no problem with these formulas, they are not an efficient method of 
programming automated lighting. Luckily, the gurus who write console operat- 
ing systems do remember their trigonometry, and they have created wonderful 
interfaces for us to use. Everything from premade circles to rainbow chases to 
hand-drawn shapes are now as easy as one press of a button. I even know of one 
console that will allow you to enter your own trigonometric formulas to apply 
effects (why you would torture yourself in this manner I do not know). In order 
to create original effects and not just utilize the premade shapes of a console, it 
is extremely important to understand the underlying principles at work within 
an effects generator. 


The DMX Protocol 


The DMX protocol of a fixture is based on a number of control channels, each 
with 256 values. The value of each channel relates to a specific function of the 
fixture. Since most fixtures have a dimmer channel where a value of 0 is no 
output and a value of 255 is full output, I will use this in my examples of 
effects. If you want to create an effect that dims the fixture up and down, 
then you will need something that changes the value of the dimmer channel 
from 0 to 255 and back down to 0. This effect will have to send all values 
between 0 and 255 so that the dimming is linear and does not appear erratic. 


Trigonometry to the Rescue 


In order to task the console with automatically fading your fixture, you can 
assign a sine wave effect to the dimmer channel. I will not bore you with the 
definition of a sine wave, but I will explain what it means to the average 
lighting programmer. Most automated lighting consoles have some sort of 
effects generator and the terminology will be different with each; however, 
the basic concepts remain the same. A sine wave is a curve that starts from a 
base value and increases and decreases the same amount from that starting 
point at a specified rate. If you start with a dimmer value of DMX-128 
(50%) and have a full sized sine wave, then your fixture will dim up and 
down at a rate defined by your console (see Figure 5.2). 


Modifying the Starting Point 


Because the sine wave is increasing and decreasing the same amount from 
the starting point, a full-sized effect will cause the fixture to dim up and 
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FIGURE 5.2 An example of a sine wave effect with a base value of 128. 
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FIGURE 5.3 An example of a sine wave effect with a base value of 255. 


down. If you start with a value of 255 and apply a full-sized sine wave, then 
the values will increase above 255 for half of the sine wave. Because DMX 
protocol does not allow for anything higher than 255, the dimmer will 
remain open for half of the effect and only dip to 128 (50%) for the other 
half (see Figure 5.3). 


Modifying the Size and Rate 


If you alter the size of the sine wave, you can produce an effect that travels 
through different portions of the DMX protocol. For example, a sine wave 
with a starting point of 128 (50%) at full size will travel from 0 to 255. 
However, the same effect with a size of 50% will yield a fade from 64 to 
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192 (25-75%). In a similar fashion, the rate of the effect will adjust the speed at 
which the fade occurs. By adjusting the effect’s rate, you can slow down or 
speed up the fade. However, it is important to remember that although your con- 
sole might send the DMX values at an extremely fast rate, your mechanical fix- 
ture probably will not be able to keep up. For instance, if you have a sine wave 
on a dimmer fading from 0 to 255 and you set the rate to 2000 cycles a second, 
you will probably only see the fixture increase and decrease slightly from the 
base value. This is because most mechanical dimmers cannot move this fast. 
However, many times this will create a totally unexpected result that can be uti- 
lized in your programming. 


Offsetting Each Fixture 


Now you should be able to create an effect where all your fixtures are dimming 
from 0 to 255. Because all your fixtures have the same effect, size, and rate, 
they will be dimming together. Most consoles allow you to alter the starting 
point of the effect. For example, by default all your fixtures might be starting 
at a point in the sine wave equal to DMX-128. However, if you offset the 
point in the curve where each fixture starts, then your effect will be much 
more dynamic. If you have six fixtures in a row on a truss and you adjust 
the offset of each slightly more than the previous (the second fixture starts 
its fade after the first), then you will have created a linear dimming chase 
(see Figure 5.4). If you randomly adjust the offset, then the fixtures will be 
randomly dimming up and down. 


Different Wave Forms 


Usually your console will offer different types of effects waves or tables to 
choose from. Some of these include sine, cosine, sawtooth, step, and ramp. 
Each of the different effects will alter the way the DMX values are changed. 
For example, a step effect will jump from one value to another without 
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FIGURE 5.4 An example of offset starting points within a sine wave effect. 
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FIGURE 5.5 Examples of ramp and step wave effects. 


crossfading. A ramp effect will crossfade in one direction and snap in the 
other. It is a good idea to familiarize yourself with the definition of each effect 
provided in your console (Figure 5.5). 


Other Parameters 


Now that you have a basic understanding of how effects operate on the dimmer 
channel, let’s look at a couple more complex situations. Many hard edge 
fixtures include an iris, and often the protocol for this channel will include 
built-in effects (see Table 5.1). 

If you wanted to create an effect that opens and closes the iris, then you 
would need a starting value of 64 and a size of 50 (resulting in a DMX output 
of 0-128). Otherwise, your effect would travel into the portions of the protocol 
used for iris strobes and ramp snaps. In the same manner, if you want to build 
an effect that bounces between two gobos, you will need to find an appropriate 
starting point and size. For instance, the base value of the effect should be equal 
to a value between the two gobos and not a value equal to either gobo. When 
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TABLE 5.1 Sample Iris DMX Protocol 


DMxX Channel DMX Value Effect 
9 Iris 0-10 Closed 
11-119 Varied sizes (small to large) 
120-130 Full open 
131-200 Varied speed ramp snap (includes shutter) 
201-240 Varied speed iris pulse 
241-255 Full open 


building effects, it is a good idea to have the fixture’s DMX protocol nearby so 
you can verify which DMX values to assign to the effect. 


INTENSITY EFFECTS 


Once while programming for a concert tour, I realized how I often use effects 
on the intensity channel of fixtures as a primary tool when programming. Most 
automated lighting fixtures have a strobe function; however, I very rarely use 
this parameter for several reasons. First and most important, it can be near 
impossible to synchronize various fixture types, even when they come from 
the same manufacturer. There is no standard for how fixtures should strobe, 
so their speeds vary greatly. Furthermore, most manufacturers will limit the 
strobing capabilities to keep their fixtures quiet or within an acceptable working 
tolerance. I often find I can strobe a fixture faster from the intensity channel 
than from the strobe channel. Note that many fixtures now have a function 
called lamp strobing that will electronically flash the lamp as opposed to 
mechanically shuttering the output. In most cases, the lamp strobing function 
cannot be recreated via the intensity channel. Second, if the production might 
be changing fixture types in the future, I can ensure that the programming 
will remain the same since the strobe is generated from the desk and not the 
fixture. Third, If I need to change from a strobe to a softer fading effect, it is 
easy to do so with a simple change to the effect. By utilizing effects on the 
intensity channel, I gain all the preceding benefits, plus much more. 


Adding Dynamics 


When using intensity effects, I find that the programming of the show can also 
be much more dynamic. For instance, instead of just launching in or out of a 
fixture-based strobe, I can crossfade in or out of the effect-based strobe at 
any time I desire. Imagine that as a song builds with intensity and the beat 
gains in volume that the fixtures start strobing faster and faster to match the 
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beat. Also, when working with other effects such as a fixture movement or color 
changes, it becomes very easy to synchronize my intensity effects with these 
other effects. If I were to use the fixture-based strobing, it would be extremely 
difficult to synchronize with console-based color or position effects. 

As with any effect you build, you must first consider the base value of the 
parameter you will apply the affect to. I almost always start my intensity effects 
with a base value of 50%. This is because when starting with an intensity of 
50% and applying a sine wave, the effect will raise and lower the intensity 
value above and below 50%. But if you start with a base value of 100% then 
the effect will only lower the value below 100%, as intensity can never be 
higher than 100%. 

Once you set the base value of the intensity, then you must select a wave 
table for the effect. A sine wave will evenly raise and lower the intensity 
value, while a step will snap from one value to another. Both are extremely 
useful, but they result in very different looks on stage. If I have assigned my 
intensity base value at 50% and select a sine wave, then the fixture should 
begin dimming up and down. The amount that it will dim will be based on 
the “size” of the effect. By adjusting the size I can make the fixture fade 
from 0% to 100%, then back to 0% and keep repeating. Now I have created 
a basic dim chase, with my fixtures all dimming up and down together. If 
I change the table to a “step” type then I will see the fixtures jumping from 
0% to 100% back to 0%, and so on. 


Adjusting Intensity Effects 


As previously mentioned, effects engines allow you to also adjust the speed 
of the effect so you can match the beat or create the desired interval for the 
effect. So by increasing the effect speed, I can amplify the speed of my dim- 
ming or strobing. Just like magic, I can quickly have my entire rig strobing or 
dimming on and off in a synchronous manner. What if I want to randomize 
the effect across my fixtures? This can easily be achieved by adjusting the 
effect’s offset. By changing the point at which each fixture begins in the 
effect table, I can stagger the effect to make it appear to be occurring ran- 
domly among my fixtures. Many consoles allow you to fan or align the effect 
offset based on the order of your fixture selection. This means you can have 
the effect appear to be moving from stage left to stage right, or make it appear 
randomly all over the stage simply by changing the order you select your fix- 
tures before fanning. 

My favorite intensity effects are random dimming of fixtures and strobing of 
fixtures either randomly or synchronized. I love to add a slow, random intensity 
fading effect on top of an audience ballyhoo (or movement) during a ballad. 
This adds another dimension to the ballyhoo and also makes it feel more 
“organic” as the beams randomly fade in and out in various areas of the audi- 
ence. Alternately, I will add strobing effects whenever needed to intensify the 
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energy of the fixtures as the music changes. The more you work with intensity 
effects, the more you will become familiar and comfortable with your 
console’s effects capabilities. Then you can apply the knowledge to many 
other parameters and create countless dynamic and interesting effects. 


Use Effects Wisely 


Effects generators are wonderful tools for lighting programmers; however, they 
can also be very annoying when overused or used without understanding. All 
too often I see people who use these generators for the majority of their 
programming yet have no idea what is going on. For example, if you need to 
create a ballyhoo on stage and select a premade effect from your console, 
then you should take the time to adjust the starting value and size so the fixtures 
only move in the desired locations. By looking at effects as another item in your 
bag of tricks, you can effectively utilize them in your show. 


KICKIN’ IT OLD SCHOOL 


I have been programming automated lights for so many years that often I forget 
the education that occurred in my early years. Just as we programmers learned 
what to do with the fixtures and consoles, so did the manufacturers. Many tasks 
that had to be created by hand are now automatic functions of the fixtures or 
desks. However, I still apply the concepts I learned in the beginning with 
every programming session I am involved with. Many of these “classic” pro- 
gramming techniques are lost in a wash of autogenerated effects in modern 
shows. 

One of my favorite “old school” position-building exercises was used to cre- 
ate circle chases in the past. In order to have fixtures moving in a circle (either 
together or spread out) we had to first chart the positions manually. This was 
achieved by marking the stage with 8 to 12 positions in a circle shape. Then 
time was spent (and lots of it) focusing every fixture to each mark on the 
stage and recording each of these positions. Finally, a chase could be built to 
have the fixtures move together from point to point, thus creating a circle on 
stage. If we wanted the fixtures to appear spread out, then we could simply cre- 
ate the chase by placing one or two fixtures on each point in each step of the 
chase. Then as we built the chase we would continue to move each fixture(s) 
to the next point and record this as a step. The look on stage was amazing, 
as the fixtures would encircle the stage and the beams would criss-cross in 
the air. Of course, today this same effect can be achieved by placing all the 
fixtures in the center of the stage and applying a circle effect. Then the program- 
mer can simply adjust the size or rate accordingly to change the appearance 
on stage. 

Although modern lighting consoles contain many powerful functions and 
features, it is very important for a programmer to understand the principles 
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and processes needed to create complex chases without the use of these newer 
functions. While effects and other tools greatly increase programming time and 
productivity, they often leave productions lacking in originality. All too often 
effects are relied upon to quickly create many chases, without the 
programmer or LD really paying attention to the nuances occurring on stage. 
The best programmers in the business know how to mix hand-built chases 
with effects to create dynamically pleasing looks on stage. 


The Fireworks Chase 


Here is the situation: You have twelve hard edge fixtures and a nice backdrop. 
You want to give the impression of individual firework shells going off in the 
distance (see Figure 5.6). One way to achieve this effect would be to have one 
fixture come on, expand like a firework, and disappear. Then repeat similar 
looks with the other fixtures one at a time. 

A common method of creating this chase would be as follows. You first 
need to build a look with all twelve fixtures on the backdrop. Place each fixture 
in a different location and in different colors and/or gobos. As you build this 
look, remember that the image with all fixtures on at the same time will not 
be seen, only one fixture at a time. So do not worry if some fixtures overlap 
or contrast with each other. Now that the look is built, you need to preset the 
fixtures for the chase. Select all twelve fixtures, set the iris to the smallest 


FIGURE 5.6 Fireworks gobos used with a fireworks chase. 
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setting, and close the shutter. Record this as cue | of the chase. Now again 
select all twelve fixtures, set the iris to the smallest, and close the shutter. 
Record this as cues 2—12 with a crossfade time of zero. I am assuming your con- 
sole uses tracking; if not, then record cues 2—12 the same as cue | (with all 
values for all fixtures). Now you should have twelve cues with all fixtures 
set to small iris and a closed shutter. Of course, on stage this will appear as 
no output, so obviously there is more work to be done! 


Making the Magic 


To make the real magic of this cue, you must now edit each of the twelve cues. 
In the first cue, select fixture 1 and open the shutter and assign the iris to full. 
Rerecord these changes to cue 1, then begin editing cue 2. In cue 2, select 
fixture 2 and open the shutter and set the iris to full. Continue similar edits 
through all twelve cues. Now when you play the cuelist, or chase, you will 
see each fixture open its shutter and iris out. Then when the next step of the 
chase occurs, that fixture will close its shutter and another will open its shutter 
and iris. You will need to adjust the rate of the chase to match the speed of the 
iris in your fixtures (usually around | second a step). 

The great thing about building a chase in this manner is that it has the 
mark cues built in. As each fixture closes its shutter, it will also reset its 
iris to the minimum setting. This allows it to be ready to repeat the look 
the next time the cue comes around. In addition, to make the chase more 
interesting, you can randomize the order. If your console will play chases 
in random order, you don’t worry about which fixture is set up for the next 
cue, as they all are always preset. When using a console without a randomize 
feature, you can create the original cues in a random order. Instead of selecting 
the fixtures in numeric order while editing cues 1-12, you could select them 
randomly. I usually write out the numbers | through 12 on a piece of paper. 
Then as I randomly edit each fixture, I put a check mark next to each one 
that I have used. This way I do not repeat any fixtures and I know when 
I have used all of them. 


Timing 

It is important to understand why this chase works with a zero crossfade time. 
The shutter will open and close instantly, yet the iris will take about one second 
to open. This is due to the mechanics of the iris. To change the look on stage to 
appear like raindrops, you can simply select different gobos and colors and put 
a crossfade time on the iris. If you slow down the iris (to around two seconds) 
and increase the amount of time on each step, then the cue will appear different. 
If your chase is running faster than the iris moves, then you will not see the iris 
fully open. In this case, add more time to remain on each step of the chase 
longer. 


56 Chapter | 5 Intermediate Programming 


Modern Miracles 


This section is entitled “Kickin’ It Old School” because in the early days of 
automated lighting programming, this is how we had to build our chases. 
Now many consoles and fixtures have built-in effects. Take a look at the 
DMX protocol for most hard edge fixtures manufactured today and you will 
find a “ramp snap” or “pulse” setting for the iris. These will close the shutter 
and iris on the fixtures and then randomly open them one at a time. By using 
this setting, you no longer have to program a chase to create a fireworks effect. 
In addition, most automated lighting consoles contain effects generators that 
can be used to ease in the programming of these looks. 


Applying Concepts 


Hopefully you can begin to form other ideas from this basic programming 
concept (e.g., if you need to create a color that sweeps through a series of 
fixtures). By applying the lessons learned with this simple fireworks chase, 
you should be able to create a chase that adds in a color mixing parameter 
one fixture at a time while resetting from the previous step. In addition, this 
exercise reinforces the practice of building mark cues and repetitive tasks. 
The next time you find yourself in a situation where you need to make a 
large chase that resets after each step, think about building all the marks 
first, then going back and editing in the actual changes. We lighting program- 
mers have many tricks at our disposal, but we must look at each situation and 
decide how to apply them for any given situation. I do not build as many fire- 
works chases today as I did many years ago, but I certainly use the methods I 
learned from it on every show. 


COMMON CHASES 


The following list describes some common chases that make for great program- 
ming exercises. Each one makes use of various programming principles and 
concepts. A good lighting programmer should be able to build any of the 
following fairly easily. In addition, the programmer should recognize multiple 
methods for creating each look, such as using built-in fixture effects or console 
effects generators. 


1. Kicks—AII fixtures are blacked out and pointing down on the stage. One 
at a time, a fixture will turn on its intensity and move to a position 
pointing upward. As it finishes its move, it will blackout and return to 
its starting position while at the same time another fixture will begin a 
similar move. 

2. Ballyhoo—All fixtures move about in an area (stage or audience) in 
a random fashion. 
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a 


10. 


. Stabs—All fixtures are irised down to their smallest size and placed in a 


static position with no intensity. Then one fixture at a time snaps to full 
intensity. As each fixture snaps on, the previous fixture snaps off. Often- 
times, stabs are built using multiple positions with the fixtures changing 
positions when blacked out. 


. Fading pulse—All fixtures randomly fade intensity from 0 to 100%. 
. Indigo/red—A rapid snap change from an indigo or congo color to a red or 


orange color. Usually all fixtures change at the same time. 


- Random strobe—All fixtures strobe at various rates to create a random 


strobing effect. 


. Fireworks/droplets—Fireworks as described earlier snaps the intensity to 


full and irises out fixtures one at a time in a random order. Droplets is very 
similar; however, it snaps the intensity to full and irises in fixtures one at a 
time in a random order. 


. Line chase—All fixtures are blacked out, then turn on one at a time in a 


linear order. Usually this chase is used with fixtures placed all in a row. 


. Smooth color mix (rainbow)—Color mixing fixtures crossfade through all 


possible colors except white. This is often created with six steps or cues, as 
shown in Table 5.2. 

Gobo rockers—Rotating gobos are set to an indexed position and then 
crossfaded or snapped between two indexed positions. This causes the 
gobo to rock back and forth. 


There are many variations on these chases as well as multiple names and 
descriptions. Over time you should learn to recognize common programming 
principles and develop many that are unique to your style of programming. 
Although many of these chases can be created using effects engines, it is 
equally important for a programmer to know how to hand-build chases of 
these sorts. With practice, any programmer can learn the lost art of chase build- 
ing and bring a fresh, creative look to any production. 


TABLE 5.2 Rainbow Color Chase 


Step 1 100% cyan, 0% magenta, 0% yellow 
Step 2 100% cyan, 100% magenta, 0% yellow 
Step 3 0% cyan, 100% magenta, 0% yellow 
Step 4 0% cyan, 100% magenta, 100% yellow 
Step 5 0% cyan, 0% magenta, 100% yellow 


Step 6 100% cyan, 0% magenta, 100% yellow 
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FANNING 


Automated lighting consoles have many innovative functions to help the 
programmer. Generally, most consoles offer many of the same features that 
have become commonplace for the automated lighting programmer. One of 
these is called “Fan” or “Align.” In the simplest terms, this is a tool that 
mathematically spreads parameter values in even proportions. From a visual 
standpoint, fanning provides the ability to quickly create symmetrical (or even 
asymmetrical) looks on stage. This feature can be found on the majority of 
professional automated lighting consoles, and it is important to understand the 
uses and procedures associated with Fanning or Aligning. 


The Origins of Fanning 


In the time before automated lighting, most rock-and-roll lighting rigs consisted 
of large numbers of parabolic aluminized reflector lamps (PARs) and aircraft 
landing lights (ACLs). These single-focus fixtures would need to be positioned 
in unique patterns that illuminated the stage, yet also created interesting beam 
looks in the air. In fact, ACLs are still often used today, and 99% of the time 
they are focused in a fanned out position. The best way to describe a fanned 
out position is to look at your hand with all your fingers placed together. Now 
spread out your fingers as wide as possible. You have now “fanned out” your fin- 
gers. In a similar manner, imagine focusing lights so that they are spread out an 
even amount from each other. This is your basic fanned out positioning. 

As automated lighting fixtures became mainstream, programmers often 
found themselves positioning fixtures in a fanned orientation. Sometimes it 
took considerable time to move many fixtures into a perfectly symmetrical, 
fanned out position. Thanks to some very intelligent console developers, we 
were blessed with an automated function that helps lighting programmers 
quickly create fanned out positions (and much more). 


Basic Fanning Procedures 


Fanning the positions of automated fixtures is a very simple task. Typically, the 
user will hold down a Fan or Align key and adjust the parameter (pan or tilt). 
The console will then spread out the values to evenly vary the result for each 
fixture. For instance, imagine you have five fixtures, each with a pan value 
of 50%. If you now hold down the Fan key and adjust the pan value, you 
could end up with the result shown in Table 5.3. 


TABLE 5.3 Fanning Pan Values from 50% 
Fixture 1 Fixture 2 Fixture 3 Fixture 4 Fixture 5 


0% 25% 50% 75% 100% 
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TABLE 5.4 Fanning from the Start with Pan at 50% 
Fixture 1 Fixture 2 Fixture 3 Fixture 4 Fixture 5 


50% 60% 70% 80% 90% 


The console has kept the middle fixture at 50% and increased the value 
of fixtures 4 and 5 an even amount. It has also decreased the value of fixtures 
1 and 2 by the same amount. The result on stage is that the fixtures are now 
spread apart across the entire stage, similar to the earlier example of spreading 
your fingers apart. 

This example assumes that your console defaults to fanning from center, 
which is the typical default on most consoles. However, many consoles also 
allow you to change the direction of the fan. For example, if you choose to 
fan from the start, then the fan adjustment as above could appear as that 
shown in Table 5.4. 

In this example, the console has left the first fixture at the starting value of 
50% and incrementally increased the value of the subsequent fixtures. The end 
result on stage will appear as all the fixtures pointing further and further off one 
side of the stage. Depending on your console manufacturer, you should have a 
number of different fanning patterns or options to choose from. Consult your 
console’s user manual or help files for further details. 


THE ORDER OF FIXTURE SELECTION 


One of the big keys to using fanning is to understand that the console will look 
at the “order of fixture selection” and apply this to the fanning tool. In the 
previous examples, we assumed that the fixtures were selected as | through 5 
(in numeric order). The fanning was then applied based on this selection and 
resulted in a symmetrical look on stage. However, if the fixtures had been 
selected as 3, 2,5, 4, 1, then the fanning would have been applied in a different 
order. For instance, with a standard fan from center (the first example) the result 
would have been that shown in Table 5.5. 

On stage, the fixtures would appear to be positioned randomly and criss- 
crossing each other as opposed to an even spread across the stage. While the 
order of fixture selection can be used to create random-looking fans, it can 
also be used to create interesting selections of fixtures. For example, 
maybe you want to fan the pan position of fixtures that are in line with 
each other, but on different trusses. The user numbers used in the fanning 
procedure may be 31, 252, 7, 104, 108. By carefully selecting the order of 
fixture selection, unique and interesting looks can be created through the 
use of fanning. 
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TABLE 5.5 Fanning with a Random Fixture Order 
Fixture 1 Fixture 2 Fixture 3 Fixture 4 Fixture 5 


100% 25% 0% 75% 50% 


But Wait! There’s More... 


Hopefully, you now have a basic understanding of the principles and uses of 
a Fan or Align tool to aid with the positioning of automated lighting fixtures. 
However, fanning can be used with any parameter and is not limited to only 
pan or tilt values. Look back at Table 5.3 and imagine that the values are for 
the magenta parameter instead of a pan parameter. You can quickly see that 
this would create an incrementing saturation of magenta from one side of 
the stage to the other. Fanning is a great method to create varied amounts 
of parameter values in a quick methodology. One of my favorite uses is to cre- 
ate random strobe values for fixtures that do not have built-in random strobe 
features. I will select my fixtures in a random order, set them all to an average 
strobe speed, and then fan the strobe value a small amount. This will ran- 
domly increase and decrease the strobe value for all fixtures, resulting in a 
unique strobe value for each. It is important that I select the fixtures in a 
random order; otherwise, it could appear that the strobing gets faster when 
viewing from one side of the stage to the other. As you can see, fanning 
values of various parameters can result in many dynamic and exciting looks 
on stage. 


Now is the Time 


Most automated lighting consoles also allow timing values to make use of the 
Fan or Align tool. The results are very different whether applied to fade or delay 
times, but both have very distinct looks that are key to energetic programming. 
For instance, if five fixtures have a fanned fade time of 1 through 5 seconds, the 
result is as shown in Table 5.6. 

All fixtures will begin moving at the same time, but they will incrementally 
take longer to get to their destination. Likewise, if the same fanned time is 
applied to the delay value instead, then each fixture will wait longer to begin 
its move. This results in a stepped peal-effect on stage. The method for applying 
fanning to timing values varies from console to console, so refer to your 
console’s manual for full details. 
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TABLE 5.6 Fanning Time Values 
Fixture 1 Fixture 2 Fixture 3 Fixture 4 Fixture 5 


1s 25s 3S 4s 5s 


Stay Cool as You Fan 


Fanning of positions, various parameters, and timing is an extremely powerful 
tool that enhances any lighting programming. It is important for a programmer 
to understand the procedures for using fanning as well as the various parameters 
and options associated with the tool. While fanning is not a required function of 
programming, it certainly is a key tool in any programmer’s belt that ensures 
added creativity and uniqueness for every production. 
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The many facets of automated lighting programming allow for different levels 
of programmers. Very accomplished programmers may never utilize show con- 
trol or visualization, while others will depend upon them during nearly every 
production. Budgetary and time constraints often dictate the use of advanced 
programming functionalities, while in other cases these concepts are used to 
further the capabilities of the lighting. It is important for an automated lighting 
programmer to be aware of the advanced programming techniques that he or 
she might encounter. 


DEFAULT VALUES 


An automated lighting programmer can gain lots of information from the user 
manuals of consoles and fixtures. However, there are many practices that 
go beyond just the capabilities of the console. Understanding how certain func- 
tions can be used to enhance your programming abilities is one of the great 
traits of successful lighting programmers. While most beginners jump at the 
chance to learn about loops, chases, effects, and other standard programming 
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tools, many miss the more subtle capabilities that can greatly improve their 
programming experience. Experienced programmers utilize these “tricks of 
the trade” every day, often without realizing just how important the methods 
are to their programming. Understanding the power of default values for fixture 
parameters can be very advantageous to every lighting programmer. 


Using Default Values 


All automated lighting consoles define a default value for each parameter of 
every fixture in the patch. These values ensure that when you begin program- 
ming, your fixture is set in a neutral position and with its parameters free of col- 
ors, gobos, and so on. Conventional fixtures typically default with an intensity 
of zero, while automated fixtures require special values for each parameter. For 
example, a simple fixture will have its pan and tilt defaulted at 50%, iris at an 
open value, gobo and color wheels at an open value, and shutter set to open. 
These “open” values are often not a DMX value of zero, but rather a specific 
reference as defined in the fixture’s DMX protocol. The more complex the fix- 
ture, the more complex the set of default values will need to be. Digital fixtures 
and media servers have very detailed default value requirements due to the 
complexity of manipulating media elements. Many parameters must be set to 
specific values to ensure that an image is visible from the device. If the 
image size, x or y position, or even brightness is defaulted to the wrong 
value, the output could be blank. 

Luckily, the initial default settings for fixtures are determined by the con- 
sole manufacturer within their fixture library. Typically, the automated light- 
ing programmer does not need to know what is required to prepare a fixture 
for programming. However, it is important that you understand these default 
values and know how to restore them quickly if needed. A common trick is to 
create a palette or preset that will restore your fixture to its default values. 
Then this palette can be quickly recalled to “reset” the fixture. For instance, 
suppose in the middle of programming a media server show, you wish to 
remove the current settings from the server. You don’t want to release the cur- 
rent playback, but you do want to begin programming a new look without the 
same parameter values that are playing back on stage. You could select each 
parameter and adjust it back to what appears to be an “open” value, or instead 
you could simply select your default palette and instantly restore the initial 
settings. This is especially important when working with automated shutters 
or digital keystone correction. If the fixture moves to a new position and 
you need to update the shutter or keystone parameters, it is often easier to 
reset these values to default than to adjust from the previous cue’s value. 
Often a programmer will make several default palettes based on parameter 
type, in addition to just one large default palette. Some lighting consoles 
also have simple keystrokes that allow quick recall of default values on a para- 
meter-by-parameter basis. 
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Custom Default Values 


Another important secret of experienced automated lighting programmers is to 
alter the console’s default values for fixtures before programming even begins. 
This ensures that fixtures are set up as needed for each particular show, instead 
of in a generic method as defined by the console manufacturer. I always take the 
time to align all my fixture positions so they are each pointing downstage as 
a default. Normally, a lighting console will orient fixtures so they are pointing 
straight down or 50/50. However, when building position palettes this can often 
lead to fixtures panning and tilting in different directions. For this reason, I first 
determine a starting position for each of my fixtures that works with the current 
lighting rig. Then I know that as I grab each light to build position palettes, I am 
panning and tilting in the same direction. This reduces my chances of experien- 
cing accidental “flips” between positions. 

Programmers also alter the default values for parameters such as zoom, 
focus, color, frost, and special modes. Just like with position, the console 
manufacture will often set focus and zoom to a value in the middle of their 
range. While this is useful in most cases, you might know that in a particular 
production the fixtures will need to be always zoomed out. Furthermore, you 
might decide to set the frost parameter all the way in or the CTO flag at a certain 
percentage as a default. Any changes to the default values will guarantee that 
these parameters are always assigned as needed for a specific production 
(until you make changes within cues). 

You should take some time to examine the capabilities of the fixtures you 
are using and the requirements of the production. Then you will be able to 
best determine how to configure your default values. You must also study 
your console’s user manual to learn how to manipulate these values. However, 
always use caution when manipulating default values because while they can be 
helpful, they can also be very detrimental if set incorrectly. For example, 
defaulting a fixture to always have an intensity of full would mean that when 
you release all programming, the fixture would remain at full! 


Study the Defaults 


You should take the time before working on a production to study how your 
console sets up the default values for fixtures. Since most fixture manufacturers 
do not provide suggested default values, these can vary from console to con- 
sole. In fact, some fixtures that utilize different modes may behave differently 
due to their defaults when working with different consoles. For example, some 
fixtures utilize color modes that change the behavior of the color mixing chan- 
nels. These modes could be defaulted to different values from one console to 
another, resulting in the fixture behaving differently just because it is pro- 
grammed on a different model or brand of desk. It is essential that programmers 
understand these defaults and be prepared to change them if needed. 
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Deciding upon Defaults 


While a programmer can just sit down at a console and begin programming, it 
can be very beneficial to make important changes to default values prior to pro- 
gramming. By understanding the predefined defaults, knowing how to restore 
them, and altering them if needed, a programmer can greatly improve his or 
her efficiency when programming a show. Careful planning and studying of 
default values can guarantee that fixture values are optimized for each produc- 
tion’s unique requirements. 


VISUALIZATION 


Many years ago I attended a lighting seminar in New York. While there, I met 
another student who told me about a new product about to be introduced at the 
upcoming Lighting Dimensions International (LDI) tradeshow. He said some 
friends in Canada had developed software that allowed them to program their 
moving lights by looking at a representation of them on a computer screen. 
This software would allow them to preprogram in a virtual world and then 
later plug in the real fixtures. They hoped their new idea would start a revolu- 
tion in the automated lighting world. This software quickly grew into the pop- 
ular visualization tool we know today as WYSIWYG (What You See Is What 
You Get). 

There are now several different brands of lighting visualization software, 
and even some lighting consoles with built-in or proprietary software. All of 
these programs serve one basic purpose: to allow you to see the final result 
of your programming data without attaching genuine fixtures. 


How It Works 


Visualization software in its most basic form is a virtual lighting rig that you 
program using any standard DMX console. The software does little more than 
emulate what a real lighting rig would do, thereby allowing programmers 
to use their console to create or edit a show without an actual lighting rig. 
All programming data and cueing remains in the lighting console, making 
the transition to a real lighting rig very simple (just plug in the DMX). 
Early versions of the software were simple wire-frame drawings of the 
fixture’s output, but now sophisticated rendering systems and even three- 
dimensional (3D) environments are commonplace. Consoles can directly 
connect to visualizers via console- or manufacturer-specific networking proto- 
cols, thus eliminating the need for the DMX input devices of the past. Visua- 
lization software can do many things to aid a designer and others involved 
with a production; however, for the purpose of this book I will focus on the 
programming aspects alone. 
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Benefits 


One of the biggest reasons to use visualization software is the substantial sav- 
ings involved. If you can spend half of your programming time in the virtual 
world, then the production will save thousands of dollars. The cost to rent a 
venue, hire a crew, rent equipment, and so on is usually much higher than 
the use of a console, computer, and software. This means that quite often 
your programming time can increase, allowing more flexibility and creativity 
in your work. In addition, the FOH area can be anywhere you like. You can 
work in a comfortable environment at any hours you and the LD desire. 

Building cues while staring at a computer screen also has other advantages. 
I usually find the programming time with visualization a great period to “learn” 
the rig, the LD’s intentions, and the production details. If you discover that the 
downstage truss fixtures will not reach all the needed locations, you can easily 
move them to a new position without calling in the crew. In addition, this period 
is often used to set up everything in the console prior to programming (palettes, 
groups, colors, SMPTE timecode). 


Programming 


Programming with a visualizer is no different than programming with an actual 
lighting rig. All the functions of your console are still available to you. How- 
ever, there are many things you must consider when working in a virtual 
world. Most of the visualization programs work very hard to reproduce exactly 
how real fixtures output, but there are often differences. In the virtual world, 
things often move at different speeds than in the real world. You might find 
that your fixtures can move from stage right to stage left in half a second on 
the computer screen, but the actual fixtures are not able to move as quickly. 
When programming with a visualizer, it is very important to understand that 
you will probably need to touch up your cues. In addition, most modern fixtures 
have automated functions such as strobing or gobo wheel rotations. Often these 
speeds will also be different on screen than with a real fixture. That perfect 
strobe setting that flashed with the musical beat during preprogramming 
might turn out to be twice as fast with the actual rig. It is a good idea to 
have one of each fixture in your rig hooked up live while working with a visua- 
lizer. This way you can check the colors, speeds, and so on for that one fixture 
and learn how it differs from the computerized version. 

Most automated lighting consoles make use of palettes (also known as posi- 
tion memories, presets, focus points, etc.). These are references to specific 
values that can be recorded into cues. If you change the value of the reference, 
all your cues using it will also update. Palettes become extremely important 
when programming with a visualizer. There are too many real-world factors 
to enable you to take a show programmed virtually and run a perfect show with- 
out updating any information. For example, a slight deviation in the angle of the 
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fixtures can cause them to project in the wrong positions. The most important 
thing to remember when working with a visualizer is that it can only simulate 
the real world, and you will need to make changes accordingly. 


Cueing 


The ability to structure your show is one of the most valuable benefits of work- 
ing with a visualizer. Frequently, rough cue ideas are created virtually and later 
made complete with the real fixtures. The rough cue data, however, will act as a 
placeholder of the LD’s concepts and, more importantly, the timing of the 
show. Expect to make changes to the look of a cue simply because it appears 
much different in reality than on the computer screen. Also, when working 
with timecode, visualizers provide a superb opportunity to enter cue times 
and perfect the cueing construction. 


Two-Way Communication 


Most visualizer software packages have a method of communicating with sup- 
ported consoles. This allows an LD to create his or her drawings and paperwork 
within the software and then send the patch information to the lighting console. 
You can often use the computer mouse to point to a location on the virtual set. 
Not only will the fixtures point to this location, but the pan and tilt information 
will also appear in your console for recording to cues or palettes. Additionally, 
the use of blind or preview capabilities has greatly expanded the usefulness of 
visualization. This function allows programmers to build or preview informa- 
tion on the visualization software without outputting DMX to the lighting 
rig. During a show, the programmer can modify an upcoming cue while looking 
at a representation of it. 


Program Anywhere 


Thanks to a group of Canadians emulating real fixtures, the automated lighting 
industry was revolutionized. There are many visualization studios around the 
world where an LD and programmer can simply walk in and begin working. 
In addition to reducing costs and aiding in cue creation, visualizers are a great 
learning tool. Students can use them to learn the functions of a console and fix- 
tures with much less expense. Furthermore, by renting a visualizer and console, 
any location can become a programming studio. I have had the pleasure of pro- 
gramming large shows from the comfort of my own home (see Figure 6.1). 
Many console offline editors work directly with a visualizer, eliminating the 
need for a console altogether. I enjoy programming real fixtures as much as 
I enjoy playing “lighting video games” with a visualizer. Imagine sitting on 
a plane, preprogramming your show as if you were sitting in a venue with a 
full lighting rig. Trust me, it is a lot of fun (especially during turbulence)! 
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FIGURE 6.1 Lawrence Upton and Brad Schiller used visualization at home for a show in Brazil. 


IT’S TIME FOR TIMECODE 


Many productions require the lighting to be perfectly synchronized with the 
audio or video elements. While this can be achieved manually with a good opera- 
tor, the best method is to use some sort of show control to automate the lighting 
cues. One of the more common approaches is to use a form of timecode. 


The History of Timecode 


In the days of film (before videotape), audio synchronization was achieved 
mechanically. The film itself and audiotapes had sprocket holes that would 
allow for perfect synchronization of the two sources. When videotape was 
developed without sprockets, an electronic method for synchronizing was cre- 
ated. In 1967 the Society of Motion Picture and Television Engineers developed 
SMPTE timecode. This standard was based upon an eight-digit twenty-four- 
hour clock. 

In addition to SMPTE, there are several other types of timecode, including 
MIDI timecode (MTC). MTC is very similar to the SMPTE timecode, but in a 
different protocol. Depending on your production and your lighting console, 
you might talk about SMPTE but actually use MTC. Throughout this book, 
when timecode is mentioned, it can be any of the actual forms. 
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TABLE 6.1 Common Frame Rate Standards 


Name fps 
SMPTE 30 30 
NTSC 30 or SMPTE 30 drop frame 29.97 
EBU 25 
FILM 24 


Defining Timecode 


The first two digits represent the hour (0-23), the next two the minute (0-59), 
then the second (0-59), and finally the frame (O—xx). Notice I did not give a 
range for the frames. The frame rate will change depending upon the standard 
used. Currently there are four typical frame rate standards, each with a different 
value of frames per second, or fps (see Table 6.1). 

SMPTE 30 is the original SMPTE standard often used in the audio industry. 
NTSC 30 or SMPTE 30 drop frame is mostly used by the NTSC video industry. 
This frame rate is based on 30 fps, but two frame counts are dropped at the 
start of every minute, except for every tenth minute. EBU is commonly used 
in Europe by the PAL video industry, and FILM, as the name implies, is 
used by the film industry. 

I do not want to scare you by giving in-depth explanations of how timecode 
functions in the binary and linear worlds. However, there are many books and 
websites dedicated to the subject if you are interested in learning more. 


Timecode and Lighting 


Imagine building a very complex lighting show that executes 1200 cues in 
3 minutes. These cues coincide with specific music notes of the audio track. 
At the very moment the short production is concluded, the show repeats with 
the same perfection. This type of accuracy would be near impossible for a 
human operator to obtain, so another form of synchronized triggering is needed. 
Synchronizing your lighting to an audio or video track is a very simple process 
involving timecode. 

The first step is to decide that you need to use timecode to trigger your light- 
ing. Make sure your production has elements that will generate the timecode. 
For example, if you are working on a live play, you probably will not have a 
recorded source that the actors synchronize to. If you are working on a dance 
show where each number runs from a digital audiotape (DAT), then you 
have a sync source. You will need to work with the audio crew to ensure 
that they provide you with the type of timecode required for your console. 
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Now that you have the timecode source confirmed, you can build your light- 
ing cues as you normally would. After the cues are in the console, you can go 
back and assign a trigger time to each. Many consoles allow you to “teach” the 
trigger times to the cuelist. When using a “learn timing” method, you will play- 
back your audio or timecode source and then simply press your console’s GO 
button at the appropriate moment in the music. The console will then insert the 
timecode value for that moment into the trigger time for the cue. Later, when 
you replay your timecode source, the cues will play back at the exact time loca- 
tions when you pressed the GO button. You have essentially recorded the tim- 
ing of your GO presses into the console. I suggest reading your console’s 
manual to determine exactly how to get the timecode times into your cuelist. 


Changing Time 


Table 6.2 represents a cuelist with timecode trigger points for five cues. By look- 
ing at the differences in the numbers, you can gain a lot of information. For exam- 
ple, the last cue happens 2 minutes 41 seconds and 3 frames after the first cue. 
You can also see there is a little less than five seconds between cues 2 and 3. 
Much information can be gathered by looking at the cue triggering times. 

Let’s say you replay your cuelist and the lighting for cue 4 is not synchro- 
nized with the explosion sound on the audio track. You will first need to deter- 
mine whether the lighting cue occurs too early or too late and then modify the 
trigger time. Determining how much time to edit can be difficult, but here is a 
rough guide. Do not begin by editing single frames (unless the cue is just really 
close). Think of the frames in easier editing blocks. For instance, when using 
30 fps remember that 15 frames is half a second and 7 frames is about a fourth 
of a second. I generally begin by editing within half a second and then move to 
smaller increments. 


Hidden Dangers 


Right now you might be thinking that working with timecode is a much simpler 
process than you first thought. You are correct; however, there are some 


TABLE 6.2 An Example of a Cuelist Using Timecode 


01:00:01.21 Cue 1 
01:00:05.02 Cue 2 
01:00:10.00 Cue 3 
01:02:42.22 Cue 4 


01:02:42.24 Cue 5 
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dangers to look out for. First, you need to make sure that your timecode source 
does not change once you begin adding timing to your cues. If the times that 
reference specific points in the audio track are suddenly off by 1 minute 
13 frames, then you will have to edit all the times in your cuelist. I have 
seen many cases where the audio crew will rerecord the tracks and change 
the timecode values, or they discover they are sending the wrong format and 
change their settings. When these things happen, you can spend hours editing 
cue trigger times. 

Another element you must consider when using timecode is that there is now 
an input to your lighting console. If your show begins and you forget to turn on the 
timecode, then the audio will begin, but the lighting will not. On the other hand, if 
you leave your timecode input on while you are editing cues and the sound guy 
decides to press play on the DAT, then your console might jump to an unexpected 
cue. You need to take care to minimize timecode problems. 


Back to the Future 


Luckily, working with timecode and lighting is usually a very simple process. 
Many programmers become nervous and concerned the first time they hear that 
the show needs to be triggered via timecode. However, as you can see, there is 
not that much involved. I will warn you, though, that often LDs love to use 
timecode because they know that cues can be triggered with every single 
audio note, and you will find yourself building longer cuelists. I see this as a 
good thing, as it just means more programming time at the lighting console. 


THE MAGIC OF MIDI 


There comes a time in every automated lighting programmer’s career when he 
or she will be asked to use MIDI or MIDI Show Control. MIDI is an acronym 
for Musical Instrument Digital Interface. It was developed in the early 1980s as 
a standard method for electronic musical equipment to pass messages to each 
other. In the early 1990s, many manufacturers of professional entertainment 
equipment created a special subset of MIDI with unique commands relating 
to entertainment productions. This new protocol was referred to as MIDI 
Show Control (MSC). Many automated lighting consoles implemented MIDI 
and/or MSC to allow remote triggering of lighting consoles and other devices. 
The following is a broad overview of MIDI and MSC uses as related to auto- 
mated lighting programming. Many books and Internet resources further 
explain MIDI and MIDI Show Control in depth. 


Lighting Applications 


Generally, an automated lighting programmer will not need to be an expert with 
MIDI and MSC. However, there are four basic uses associated with lighting 
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programming that you must be aware of. The first two relate to console redun- 
dancy. Many designers insist on a backup lighting console in the event of a 
failure. Consoles connected via MIDI or MSC often have the capability of 
real-time playback tracking or complete redundancy. With real-time playback 
tracking, the main console will send MIDI or MSC commands to the second 
console, ensuring that both consoles are in the same state of playback. Any 
new programming information will exist only on the main console. On the 
other hand, complete redundancy uses MIDI or MSC to send every keystroke 
from the main console to the secondary console. In this scenario, both consoles 
will always maintain the same state, as they are performing identical key 
presses. 

The next two uses of MIDI or MSC commonly used by automated lighting 
programmers are for interaction with other devices within the production. For 
example, the automated lighting console might send playback commands to a 
conventional lighting console. In addition, a lighting console might use MIDI 
or MSC to trigger a wide assortment of devices such as audio, video, automa- 
tion, or scenic elements. In the same manner, MIDI and MSC can be used for 
triggering an automated lighting console from show control computers or other 
devices. 


MIDI Notes 


MIDI in its simplest form is a networking protocol that allows multiple devices 
to communicate with simple commands. The command set includes note-ons, 
note-offs, key velocity, pitch bend, and other methods designed for controlling 
a synthesizer (see Table 6.3). Sometimes basic MIDI is referred to as “MIDI 
Notes” due to its musical structure. 

To aid with large configurations of equipment, MIDI specifies 16 discrete 
MIDI Channels. This enables a single cable arrangement to control up to 16 
different devices at once. The model of MIDI Channels is similar to the con- 
cept of a DMX address. Each device is assigned a MIDI Channel number and 
will listen only to commands sent to that channel. In this manner many devices 
can be connected in series, yet each device will only respond to commands 
specific to that device. For example, a show control computer might send com- 
mands to an automated lighting console, a conventional lighting console, and 
an audio desk. All devices will receive the same data from the show control 
computer, but each will respond only to its unique commands as defined by 


TABLE 6.3 Basic MIDI Commands 


Note on Note off Poly key Control Program Monokey Pitch System 
pressure change change pressure bend 
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the MIDI Channel. When setting up your console to respond to MIDI informa- 
tion, you will need to assign a MIDI Channel number to the console. If your 
console will be used to transmit MIDI information to trigger other devices, 
then the output MIDI Channel will need to be defined with each command. 
Refer to your console’s documentation for further details on defining MIDI 
Channels. 


MIDI Show Control 


As the use of MIDI grew in the 1980s, many entertainment professionals saw 
the need for a specialized subset of MIDI. They developed a new standard 
known as MIDI Show Control. The command set includes load, go, stop, cue 
number, cuelist number, and fire macro. In addition, specific subcommands 
were developed for industry-based command structures. Each command format 
of MSC consists of its own types of commands related to the industry type. 
Some of these industries include lighting, audio, pyrotechnics, and video 
(see Table 6.4). 

In a method similar to MIDI Channels, MSC defines a Device ID for each 
unique device. Again, this setting allows each device to receive all MSC com- 
mands but only respond to those intended for its unique Device ID. When set- 
ting up your console to respond to MSC information, you will need to assign an 
MSC Device ID to the console. If your console will be used to transmit MSC 
information to trigger other devices, then the output MSC Device ID will need 
to be defined with each command. Refer to your console’s documentation for 
further details on defining MSC Device IDs. 

MSC transmits both commands and command data (see Table 6.5). For 
instance, an MSC message might send the equivalent of “Device ID 2 Lighting 
General Format Go Cue 2 Cuelist 7.” If a device sends this information to your 
console, it should trigger the second cue of the seventh cuelist. Unfortunately, 
many console manufacturers have chosen not to fully implement MSC. Your 
console might ignore the cuelist number portion of the command and instead 
apply the message to the currently active cuelist (or even to all cuelists). It is 
extremely important that you read and understand the console’s MSC imple- 
mentation. With a properly configured console, MSC receiving functionality 
should be relatively simple. 

In addition to receiving MSC commands, many lighting consoles also have 
the ability to transmit MSC messages. Depending upon the functionality of your 
console, this message might be editable. However, many consoles simply 
implement MSC to send commands mimicking console activities. For example, 
if you press GO for cue 2 of cuelist 7, the console will send this information out 
to a predefined Device ID. Other lighting consoles have methods to send unique 
MSC commands in the same manner as lighting cues. This ability allows the 
lighting console to behave as a show control computer by triggering various 
devices through the use of MSC. 


TABLE 6.4 MIDI Show Control Command Formats 


01 
Lighting 
(general category) 


02 

Moving lights 
03 

Color changers 


04 
Strobes 


05 
Lasers 


06 
Chasers 


10 
Sound 
(general category) 


inl 
Music 


12 
CD players 


13 
EPROM playback 


14 
Audio tape machines 


15 
Intercoms 


16 
Amplifiers 


7 
Audio effects devices 


18 
Equalizers 


20 
Machinery 
(general category) 


21 
Rigging 
22 

Flys 

23 

Lifts 


24 
Turntables 


25 
Trusses 


26 
Robots 


27 
Animation 


28 
Floats 


29 
Breakaways 


2A 
Barges 


30 
Video 
(general category) 


3H 
Videotape machines 


32 
Videocassette machines 


33 
Video disc players 


34 
Video switchers 


35 
Video effects 


36 
Video character 
generators 


By; 
Video still stores 


38 
Video monitors 


40 
Projection 
(general category) 


41 
Film projectors 


42 
Slide projectors 


43 
Video projectors 


44 
Dissolvers 


45 
Shutter controls 


50 
Process control 
(general category) 


51 
Hydraulic oil 


32) 
H,0 


53 
CO, 


54 
Compressed air 


55 
Natural gas 


56 
Fog 


57 
Smoke 


58 
Cracked haze 


60 
Pyro 
(general category) 


61 
Fireworks 


62 
Explosions 


63 
Flame 


64 
Smoke pots 


ICIW Jo s18eyw ay, | uoNda¢5 


Gy 


76 Chapter | 6 Advanced Programming 


TABLE 6.5 Basic MIDI Show Control Commands 


Reserved Go Stop Resume Timed go Load Set Fire 

All off Go/jam Standby Standby Sequence Sequence Start Stop 
clock + - + - clock clock 

Zero clock Set MTC MTC Open Close Open cue Close cue 
clock chase on chase off cuelist cuelist path path 


Standard MSC formatted messages such as Go, Fire, Load, and Pause allow 
simple communication between various devices. Some systems such as lasers 
and pyro may require additional safety requirements before their systems can 
be triggered by an external device. Usually, a human presence is required to 
ensure the ultimate safety on stage, and this is regularly accomplished with a 
dead-man safety switch. However, for timing purposes it is often best to 
allow triggering from the lighting console to ensure that lighting and laser or 
pyro cues are synchronized. Extreme care must be taken when triggering 
non-lighting devices from a lighting console. 


Be Prepared 


Unfortunately, most lighting consoles have adopted a rather poor implemen- 
tation of MIDI and MSC, thus requiring programmers to be familiar with hex 
codes and other technical jargon. Since MIDI and MSC are rarely used 
beyond simple triggering or redundant control, manufacturers of lighting 
consoles have not put much effort into creating user-friendly interfaces. It is 
essential that a lighting programmer study the user manual of the console to 
determine exactly how MIDI and MSC function within the console. Fortu- 
nately, however, MIDI and MSC use rarely appears as a last-minute surprise, 
thus allowing programmers an opportunity to analyze their console’s 
implementation. 


OTHER TYPES OF AUTOMATION 


Most automated lighting consoles also allow for a few other methods of auto- 
mated playback. Some will use analog triggering such as a 0-10 volt source. 
This allows various types of systems to send a low-voltage signal that can be 
mapped to specific console functions. Another common source of automation 
within the console itself is clock and calendar triggers. The lighting console 
will use its knowledge of the date and time to schedule and trigger various 
cue playbacks and events. Furthermore, some consoles have astronomical 
functionalities that allow the console to calculate and trigger at sunrise or 
sunset based on the console’s physical location in the world. Most consoles 
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utilize keyboard shortcuts for quick programming from a keyboard. Program- 
mers can then take advantage of original equipment manufacturer (OEM) 
products such as X-Keys or Rosco Keystroke. These hardware devices can 
play back specific keyboard instructions to allow various input and 
triggering options. 


Automation Abounds 


Our industry has created many methods for automated lighting programmers to 
automate the playback of a production. Whether being triggered by another 
device or triggering a device, it is important to understand the options. You 
should study your console’s user manual to determine what methods of automa- 
tion are available as well as how to configure and use them. In addition, there 
are several industry resources available that provide detailed information about 
working with Show Control. Once everything is configured and working, it is 
very exciting to take your hands off the console and watch it run a show all by 
itself. 
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A long time ago while attending a lighting convention, I sat in on a discussion of the 
newest innovations in automated lighting technology. At the end of the seminar, a 
well-respected LD was asked what he thought was the Holy Grail of automated 
lighting. He said that in the next 10 to 15 years all lights would be digital. He 
described a system where instead of using mechanical functions and glass to change 
the output of a fixture, everything would be generated in a video-like format. These 
digital lighting fixtures would be more than just a video projector on a yoke, as they 
would contain specific software to enable them to behave as lighting fixtures. Any 
image, any texture, any color could be projected with no limits. I was thrilled by this 
vision and hoped it would come true sooner than later. 

About 10 years later this technology finally emerged within our industry. Sure, 
many had tried in the past, but there were various problems. The first problem was 
brightness. Video projections are currently created using one of two methods. The 
first uses a liquid crystal display (LCD) screen, through which light is shined to 
cast an image on a surface. The other method is called Digital Light Processing 
(DLP). Texas Instruments created DLP by using a microchip built with hundreds 
of tiny mirrors. When a light is focused on this surface and the mirrors are turned 
on and off, they project the pixels of a video image. Video projector manufac- 
turers must work with these methods to optimize the output from a lamp without 
burning up their technology. Currently, the brightest (and largest) video pro- 
jectors output around 50,000 lumens, while midsized projectors are about 
7000 lumens. Compare this with approximately 9000 lumens of a standard 
575 watt moving light and you will see the complications. 


The Automated Lighting Programmer’s Handbook. DOI: 10.1016/B978-0-240-81553-4.00007-8 
Copyright © 2011 Elsevier Inc. All rights reserved. 79 


80 Chapter | 7 Digital Lighting: The Future Is Here 


FIGURE 7.1 Digital lighting fixtures and media servers combine with lights for total visual control. 


The other hurdle automated lighting manufacturers had to overcome was the 
programming interface for digital lighting fixtures. DMX-controlled media servers 
that allow for direct DMX control and manipulation of video sources, images, and 
various content formats are now commonplace in our industry. Automated lighting 
programmers need to be aware of this new frontier and begin to learn more about 
file formats, content creation, and other digital products. 

There are several different types of digital lighiting fixtures within our indus- 
try, and they have been used on all types of productions worldwide. The industry 
has embraced this technology, and lighting programmers now routinely program 
digital fixtures. Media servers are even more common on productions, as the price 
of LED walls and elements has been reduced. Since the visual controls of these 
devices has been placed in the hands of the lighting designers, the level of crea- 
tivity has soared. Lighting designers often place digital technology on shows so 
that the programmer can quickly and easily program and control all visual 
elements on the stage (see Figure 7.1). 

For instance, the programmer can ensure that the media content and colors 
match the stage lighting and vice versa. Since all data is programmed in the 
same cues, synchronization of lighting and video is not a problem. It is essential 
that an automated lighting programmer is aware of the unique requirements for 
programming digital lighting fixtures and media servers. 


CONTENT 


It is important to remember that although we are talking about video technology, 
the use is very different. Much of the terminology and concepts, however, are 
new to the lighting industry. First there is content. Instead of gobos, prisms, 
and other effects, digital lights make use of various computer files to play 
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back their imagery. These movies, photographs, animations, and so on are 
referred to as content or media, and content is one of the most important 
elements of a digital light. Good gobos are very important for standard lighting 
fixtures, and the same is true for content. Think about being able to project 
anything you desire onto your stage. Great; now where will you get that con- 
tent? You will need to create it, have it made, or purchase it. Luckily, the 
video industry has demanded content for years, so there is a lot of it available 
for purchase. In addition, several companies are now providing content speci- 
fically for use within the lighting industry. 

Digital lighting programmers may find it important to be skilled in content 
creation and editing. I know of many programmers who are beginning to take 
classes in computer-based video editing and animation creation. Currently, if a 
programmer is able to create and modify content while also programming the 
show, then the programmer is that much more desirable. However, there 
comes a point when a lighting programmer must focus on programming and 
not content creation and editing. 

As we head into this new frontier, it will be interesting to see who is required 
to provide and edit the content. Will the rental companies need to have a stock of 
computer files they can load into the digital lights they rent? Will lighting 
designers or even lighting programmers need to supply the content? Maybe an 
entire new profession will be created with production staff allocated to content 
design and creation. In fact, all of the above is currently happening. I know of 
several visual content artists who provide content for productions as well as rental 
companies that send out servers filled with their own content. It is also common 
for there to be a media server specialist on shows who is responsible for all 
aspects of a media server. He or she will upload content, configure output 
settings, and more. Some lighting programmers are even hired specifically to 
program digital lights or media servers while another programmer handles the 
automated lighting. It is an exciting time in our industry, as the next few years 
will shape the standards and methods for the future. 


NEW JOBS 


Wait! Did I say automated lighting programmers will be better off if they know 
how to create and modify content? Presently, the lighting programmer does not 
have to know how to create or install gobos on moving lights, so why does he 
or she need to know content creation? Right now you will find that most shows 
using digital lighting will have the lighting programmer look after the computers, 
software, and media of the digital lights. This is because the fixture technicians are 
not familiar with the technology, and the lighting programmer is also usually a 
computer guru. Furthermore, the lighting programmer interacts directly with the 
content via DMX, so it’s only natural that he or she is familiar with the digital light- 
ing software and content creation. So at this moment in this technology’s history, it 
is important for a digital lighting programmer to be familiar with the product’s 
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software as well as content creation. Someone else on the production staff should 
provide and edit the content prior to its manipulation via DMX, but this is not 
always the case. I always remind people that I am a lighting programmer and 
not a content creator/editor. If I have to stop programming the lighting to rerender 
a movie file, then I am losing time behind the console. 

Over the last few years several new production positions have been created. 
First there are digital content specialists. These people create and modify content 
specific to a production’s needs. They may simply be custom content providers or 
they may be media designers working directly with the lighting and production 
designers. In addition, there is a need for specialized digital lighting technicians. 
Besides maintaining the actual fixtures (changing lamps, adjusting DLP or LCD 
components) they are also responsible for loading content into the fixtures’ 
computers or servers, adjusting output resolutions, maintaining network systems, 
and so on. I predict that over time, all lighting technicians will gain this knowledge 
and experience, thus negating the specialist title. Both of the above positions 
enable the lighting programmer to concentrate on simply programming the lights, 
digital or otherwise. Ultimately, there will be conventionals, automated lights, 
and digital lights, and a good lighting programmer will be able to program any 
of them interchangeably. However, right now if lighting programmers want to 
become involved in this exciting new technology, they may need to fill the 
shoes of all the positions I have listed. 


POINT OF VIEW 


We now have three distinct types of lighting equipment: conventional, automated, 
and digital. Many uninformed individuals look at the new digital projection tech- 
nology as a simple marriage of lighting and video. They are quick to dismiss the 
technology as straightforward video editing that can be accomplished with com- 
mon video production tools. On the other hand, many visionaries perceive the tech- 
nology as another new lighting tool. In fact, it has the potential of being the ultimate 
lighting tool. When approached as a lighting fixture, the possibilities are endless. 
For example, we now have digital lights, digital gobos, digital backdrops, digital 
beamage, and countless other effects. No longer are we limited by mechanical 
functions such as gears, dichroics, motors, and belts. Every element projected 
out of a fixture is created digitally via a computer. When you can look beyond 
basic video functionality and into the creative digital world, then you are ready 
to begin exploring digital lighting. 


SERVERS AND DISPLAY DEVICES 


Currently, modern digital lighting technology consists of two main elements. The 
first is a media server. This computer houses all the content and generates all 
the manipulations as directed by DMX input. The second essential component is 
the display device. Digital lights, video projectors, plasma screens, LED video 
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walls, computer monitors, and other similar devices make up this category. If you 
are using a large number of media servers, you might find it best to locate these 
backstage and run video or Ethernet cables to the output devices. Now you will 
have created a “Digital Beach” right alongside the “Dimmer Beach.” 


NEW FUNCTIONALITY AND TERMINOLOGY 


Currently, there are only a few digital lights on the market, but a wide range of 
media servers. Each has its own approach to content manipulation; however, 
they share some common parameters. First is content selection. A digital light- 
ing product must allow the programmer to select items for playback. With stan- 
dard automated lights, there are gobo wheels, which usually contain six to eight 
gobos. Choosing gobos is a simple process of selecting a gobo wheel and a 
gobo. A very similar process is used for choosing content with digital lighting. 
Instead of wheels, content is stored in folders, banks, and libraries. Within each, 
a file, image, or source can be chosen. Once a file is selected for playback, the 
play mode or playback parameter can be altered to define the order in which 
content portions (or frames) are viewed. Some options include loop forward, 
loop reverse, random play, play once forward, pause, and stop. 

A good digital lighting product will first set out to duplicate the functionality 
of an automated lighting fixture. It should have functions we are all familiar 
with, such as intensity, color mixing, iris, framing shutters, strobe, image rota- 
tion, frost, and zoom. There are, of course, many other parameters that are 
unique to digital lighting. It is imperative that automated lighting programmers 
learn this new vocabulary and become familiar with its uses within digital light- 
ing. Some of the terminology as used by today’s various products is defined 
below. 


Aspect: A parameter that allows the modification of the geometry of an 
image to change its relationship between height and width of the content 
and manipulations. 

Frame rate: The speed at which content is played back. Usually displayed 
in frames per second (fps). 

Keystone: A function that allows the altering of the geometry of an image to 
alter its shape. Very useful for correcting images projected at extreme 
angles. This functionality usually consists of four to six parameters for 
total geometry correction. 

Layer: A different series of effects and/or content that can be overlaid with 
other content to create a single output. Each layer generally has its own set 
of controls that alter only that layer. Similar to multiple gobo wheels within 
an automated lighting fixture. 

Global layer: A special layer that does not play back content, but instead 
acts as a master layer that affects all other layers. A typical use of this 
layer is keystone, shutter, and other sizing information. 
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Mask: Content that is used to block visibility of another layer. The mask is 
often on a separate layer from the main content. Typically used to create 
output similar to a gobo or iris of an automated lighting fixture. 

Position: The location of content and manipulations within the raster can be 
altered on both horizontal (x) and vertical (y) axes. 

Raster: The area of active video as output from the media server. This 
boundary is defined by the resolution of the media server’s computer. 
Scale: Similar to a zoom function of an automated lighting fixture, this para- 
meter changes the size of the output within the raster. 

Shape: Allows for applying or wrapping content and manipulations around 
a 3D object or 2D shape. 

Trails: An effect that adds slowly fading out “ghosting” of images. Especially 
noticeable when rotating images or moving them within the raster. 

X rotation: Allows for indexing and rotation of content and manipulations 
around a horizontal axis in 3D space. 

Y rotation: Allows for indexing and rotation of content and manipulations 
around a vertical axis in 3D space. 

Z rotation: Allows for indexing and rotation of content and manipulations 
on a flat plane in 2D space. Very similar to standard gobo rotations of an 
automated lighting fixture. 

Visual effects: Media servers and digital lights contain various effects that 
can be applied to the output of a layer. These effects can modify colors or 
the image itself. Common effects include bubbles, image blur, pixel effects, 
and mirroring. 


PROGRAMMING DIGITAL LIGHTING 


This is an exhilarating period in lighting history, as this technology is in its 
infancy. However, this can also be frustrating, as there are no standards, common 
methods, or similar terminology between products. Luckily, the one common 
element with these fixtures is DMX control. All the programming is the same 
as any standard automated light, using the console of your choice. I suggest 
you think of these products as you would any other new fixture and first study 
the DMX protocol. Once you learn how the “aspect” parameter alters the content 
output from the fixture, then you can relate all your normal programming knowI- 
edge to this new parameter type. If you begin to get lost in the new terminology 
and are worried that you do not understand the manipulations, step back and 
remember it is just a digital moving light controlled by DMX. These products 
are very simple from a lighting programmer’s point of view, as they do not 
require any special programming talents. 

It is thrilling to apply lighting techniques to a new medium. For example, 
think of using a digital light or media server to control the imagery on an 
upstage wall. You have now created a “digital backdrop” or “digital cyc.” 
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FIGURE 7.2 A digital backdrop manipulated by the lighting console. 


This technology allows you to use any image you desire and manipulate it from 
your lighting desk. So instead of simply fading out the backdrop, you can 
program the imagery to fade to blue while scaling (zooming) and dimming 
out. The combined “lighting programming” will be viewed as new “animation” 
on the backdrop. The difference is that this magic was created with the same 
keystrokes and skills you have used on every show (see Figure 7.2). 

Lighting console manufacturers are beginning to embrace the digital tech- 
nology and add features specific to this equipment to their consoles. For 
instance, new protocols transmitted via Ethernet allow direct connectivity 
between digital lights or media servers and a console. The console can then dis- 
play content thumbnails and image previews directly on the programming 
screens. This can assist the programmer when trying to select content by allow- 
ing for quick visual references instead of just names or numbers. Furthermore, 
additional features to aid in manipulation of media server modes and improved 
fixture libraries have made programming of digital lighting much more user 
friendly. 


Enough Is Enough 


With standard automated lights, there are X number of gobos and X number of 
effects. By combining the various parameters, you can create a certain number 
of looks. However, because the possibilities with digital lighting are endless, 
you must first decide what content is best for your needs. Then you must decide 
when your manipulation of the content is enough. With digital lighting, you 
have the ability to control such a multitude of parameters that it can become 
difficult to determine which is best. Remember, there are few mechanical limits 
to hold back your creativity, which can be both a hindrance and a blessing. 
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WORKING WITH LAYERS 


Digital lighting products are very different in output and control from good old 
automated lighting fixtures. Many of these units require knowledge of their 
protocol as well as a good understanding of how they interact with a lighting 
desk. Unfortunately, the consoles of our industry have not yet fully embraced 
the capabilities and requirements of these newest products. For this reason, it 
is imperative for automated lighting programmers to be aware of the complex- 
ities and requirements of the newest offerings from lighting manufacturers. 


The Console Problem 


Automated lighting consoles are great for programming standard automated 
lights that have a single set of parameters. However, when a fixture contains 
many layers or cells of the same information, most consoles have trouble. 
For example, imagine a simple LED fixture that has three cells, each with 
Red, Green, and Blue parameters. An automated lighting console has trouble 
with a fixture that contains three sets of the same parameters because the con- 
sole expects the fixture to have only one color system. A fixture of this type 
does not fit into color picker, fanning, spreads, copy functions, and other con- 
sole features that are designed to work between fixture types, but not within a 
single fixture. So to get around this, users will patch three identical fixtures into 
their console to control one real-world instrument. In order to program this 
instrument, the programmer must select three unique fixtures on the console, 
each controlling only a part of the instrument. The downside is that users 
must remember which fixture numbers relate to which portion of a fixture, 
and some features such as Highlight or ID may not function. The benefit of 
this method is that effects, fanning, copying, and more are much easier across 
multiple “fixtures” than within a single “fixture.” 

The problem can become even more complex with media servers and 
digital lights. Most of these units use multiple layers that contain many of the 
same parameters on each layer. For instance, if you are programming a digital 
fixture you might have one motion layer, one global layer, and three graphic 
layers all that control the same instrument. To the lighting console these will 
be set up as individual fixtures, each with their own unique fixture number. 
Again, the benefits of this method far outweigh the disadvantages of having 
all parameters on one single fixture within the console. In the example above, 
imagine that each of the graphic layers contains 40 unique parameters. This 
means that if you were to select the fixture as a single unit, you would have 
well over 120 attributes to adjust at once. Never mind the fact that many of 
them repeat in name as they are applied to each layer. That is a lot of data to 
have to keep track of on the screen and with the encoder wheels on your 
desk! I would much rather select each layer one at a time and work with only 
40 parameters at a time. 


Section | Working with Layers 87 


Fixture Numbering 


When working with multi-cell LED fixtures or digital lighting, it is essential that 
you number your fixtures in a method that helps you to quickly recall the various 
portions of each instrument. When I work with digital lights, for example, I will 
number them using a three-digit system where each digit helps me to remember 
the purpose of that fixture selection. So again using the above digital light example, 
I would number the fixture as follows: 121: motion, 122: global, 123: graphic 1, 
124: graphic 2, and 125: graphic 3. I can instantly remember and locate each 
portion because I know that fixtures in the 100 range are digital lights (the 
first digit). The second digit tells me the “instrument” number; the example 
given is for digital fixture number two. Then the third digit defines which portion 
of the instrument I am working with: 1: motion, 2: global, 3: graphic layer 1, and 
so on. Now I am sure you can quickly see that if I select fixture 164 on my con- 
sole that I have selected graphic layer 2 on the sixth digital light. When I am 
working with more than nine digital fixtures I will apply the same technique 
but start my numbering in the thousands instead of hundreds. As I stated before, 
this principle can also be applied to LED cell type fixtures. Many of these units 
must be patched as a number of cells that correspond to the different sections 
within a single instrument. 


Patching the Parts 


When working with multi-part fixtures, you must remember the structure when 
patching. If you are working with the previously mentioned digital light, you 
must patch each portion in the correct order that matches the DMX protocol, 
while ensuring that the sequence starts at the DMX start address for the fixture. 
So in the example, you would patch the motion layer first at the DMX start 
address, then each of the other layers in the order that matches the protocol 
at each successive DMX address. If the layers are patched out of order, then 
the fixture will not respond correctly. Furthermore, you must take care when 
patching multiple instruments to ensure that all the parts of each instrument 
are patched before the next instrument is patched. You cannot start another 
fixture at an address that overlaps part of an existing address. 


The Missing Link 


In the future automated lighting console manufacturers need to confront the 
problem of multi-part fixtures with new console paradigms. Programmers now 
require methods to quickly select fixture “parts,” yet also be able to copy and fan 
within and between each part. New color tools should allow for quicker access to 
fixtures with multiple identical color parameters, and better layer tools should 
assist with programming routines. Further concepts will ease the patching by 
allowing each instrument to be patched and addressed as a single unit. When 
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will these features be seen in modern consoles? Soon, I suspect, as our industry 
keeps creating more and more LED fixtures, media servers, and digital lights. 
Until then, it is imperative that programmers familiarize themselves with the 
current methods for working with these instruments and become proficient at 
the above-mentioned routines. 


THE FUTURE IS NOW 


We have come a long way: from a simple ellipsoidal with one gobo and one 
color to the cutting edge of digital lighting, where we can project and manipulate 
anything we desire. In addition to controlling the output from projectors, we are 
now able to directly control the content on video walls, plasma screens, etc. 
I look forward to the exciting lighting revolution that is only just beginning! 
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LED lights are rapidly changing and growing on a daily basis—so much so 
that the automated lighting programmer is likely to use some form of LED 
lighting on every production. There are several different types of LED lighting 
categories, and each has its own unique methods and procedures for program- 
ming and control. It is important to understand the different types and the 
specific actions required for each. LED fixtures tend to fall into the following 
types: RGB mixer, RGB cell, moving light, digital light, or video element 
(see Table 8.1). 


LED RGB MIXERS 


The most basic LED fixture is a simple unit that has an array of red, green, and 
blue LEDs that can output a large number of colors. These units will either have 
individual LEDs per color or a homogenized output where each LED “pixel” is 
capable of red, green, or blue output. The latter provides a much better image 
when looking directly at the unit and also better shadows. Some fixtures include 
additional LEDs to provide amber or white output. 

Programming of these fixtures is typically accomplished via direct control of 
the colors. The additive color mixing provides the programmer the ability to use 
standard color parameters on the desk to create the output. Actual programming 
of colors with LED fixtures is pretty simple, except that instead of using a sub- 
tractive color method such as with most moving lights (CMY), LED fixtures 
use an additive color mixing method. This is because each color is derived 
from a unique light source instead of using dichroic filters to remove particular 
wavelengths of light. So if you are used to creating light lavender by dialing 
cyan and magenta, you now have to “reverse” your thinking and dial the 
blue and red. Of course, the color rendering of LED fixtures is also very differ- 
ent from that of halogen sources, so you might have some difficulties matching 
colors with the rest of your rig. 


The Automated Lighting Programmer’s Handbook. DOI: 10.1016/B978-0-240-81553-4.00008-X 
Copyright © 2011 Elsevier Inc. All rights reserved. 89 


90 Chapter | 8 LED Lighting 


TABLE 8.1 LED Lighting Categories 


Fixture Type Features Category 
LED static washers/pars Basic color mixing and intensity RGB mixer 
LED strip lights Several cells of color mixing RGB cell 
Moving LED lights Similar to a traditional moving light Moving light 
Pixelation Luminaires Specialized moving fixtures Digital light 
Tubes and tiles Low-resolution displays Video display 
LED curtains Low-resolution displays Video display 
Video walls High-resolution displays Video display 
Transformable video pixels Mixed-resolution displays Video display 


Some LED RGB products also employ additional colors such as amber or white 
to assist when color mixing. This means you now have an even more complex color 
mixing system and must take more time to create the desired colors. Since each 
color is actually additional light from another source, the color value is also the 
intensity value of the fixture. For example, a light blue color will not output as 
much light as a turquoise color that uses both the green and blue LEDs. Often 
you will find that the overall output level may factor into your color selections. 

Many of these fixtures do not include a separate intensity channel, which 
can be troublesome. For instance, bringing the grand master down to 0% 
may not affect the output if the fixture is thought of as a pure RGB unit. 
Many automated lighting consoles now provide a virtual intensity channel for 
these fixtures to aid in this and other intensity programming. 

LED static washers or pars are commonly used to wash a stage, as floor 
lights, or as truss toners. Because the units are very inexpensive, you will 
often find large quantities of them on your shows. Be sure to build groups to 
aid in programming lots of color mixing fixtures at once. 


LED RGB CELLS 


LED strip lights are very popular due to their energy efficiency and low cost. 
They are often used as standard strip lights or as effects with the output directed 
at the audience. These fixtures often have several DMX modes to select from. 
The simplest mode allows the entire unit to be used as a single color mixing 
fixture. On the other hand, the most complex mode provides direct control of 
each and every LED within the unit (could be as many as 128!). Of course, 
there are also various other modes that control different blocks (or cells) of 
LEDs within the strip. 
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Programming of these units really depends upon the mode they are set to. In 
most cases, you will need to patch each cell separately and then control these as 
unique “fixtures” within your console. Most modes also provide a generic or 
master intensity for each cell, which can be helpful when building intensity 
effects between the cells. 

A good programmer can create various dynamic chases and effects between 
the cells and then clone this information across large numbers of fixtures. In 
more advanced productions, the strips can be pixel mapped to allow direct 
video playback to occur on the units. This is always a good choice as it frees 
the programmer from building time-consuming chases by instead simply select- 
ing content on a media server. When pixel mapping, the highest DMX channel 
count mode should be used. 


LED MOVING LIGHTS 


The lighting industry is putting lots of resources into the development of 
automated fixtures that use LED sources instead of halogen lamps. Energy effi- 
ciency, ease of maintenance, fewer moving parts, and less heat are just some of 
the benefits of LED technology. The types of LED fixtures range from simple 
par or washer units on a yoke to fully developed moving lights with LED 
engines. LED technology is rapidly growing, with new developments made 
almost daily; in fact, we have already seen all types of LED-based moving lights. 
Wash fixtures, hard edge profiles, spot fixtures, and various effect units are all 
commonplace. 

Programming of these units is just as easy as with any standard moving 
light. Each unit will patch into the console as a complete fixture, with a full 
DMxX protocol and many parameters to adjust. Some fixtures allow the pro- 
grammer to choose a color mixing mode of either additive RGB or subtractive 
CMY. The latter mode emulates the color mixing of a traditional moving light, 
which can be very handy when trying to color mix both types of fixtures at the 
same time. Furthermore, many of these units allow dynamic color correction, 
adjustable lamp color correction, and various dimming curves. As always, it 
is important for the programmer to understand all the capabilities and modes 
of the fixtures. 


LED DIGITAL LIGHTS 


At least one manufacturer has created a range of fixtures described as Pixelation 
Luminaires. These units are specialized moving LED fixtures that not only 
provide an output similar to a wash light, but also dynamically display playback 
of content on the unit’s LEDs. The units operate more like a digital light, as they 
have a built-in media server that controls the content, playback options, transi- 
tions, and more. The units are very interesting because complex looks can be 
created directly from the fixture without the need for pixel mapping or complex 
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console programming. In addition, the units can appear to change their “lens” 
by changing the pattern of LED used to illuminate the stage. For instance, 
one scene may have the units wash the stage in yellow light projected from 
the shape of a plus sign. The next scene may illuminate the stage in blue 
from an image of bubbling water. 

The automated programmer must understand the basics of digital light 
programming and working with layers in order to get the most out of the 
pixilation fixtures. Most of the concepts of digital lighting directly apply to 
the programming of these fixtures. 


LED VIDEO DISPLAYS 


The final type of LED lighting commonly used by automated lighting program- 
mers is the LED video display variety. There are many different products that 
fall into this category, but they all share a similar concept. Each unit consists of 
many LED pixels that can each create RGB output from a video source. 
Although some can be controlled directly from DMX, in most cases they simply 
receive a video signal and output the imagery accordingly. Some units have 
processors that directly accept a video source, while others require the use of 
a pixel mapping program. 

Once the pixel mapping or processing is properly set up, the automated 
lighting programmer can simply program these types of devices by playing 
back and modifying content on a media server. The actual routing of the 
video pixels to the LEDs on the units is all handled through the magic of soft- 
ware. By choosing to play back content, instead of spending hours to program 
a complex chase, a show can be built in much less time and with much better 
results. 


PIXEL MAPPING 


Probably the most exciting and creative method of controlling large arrays of 
LED products is through the use of pixel mapping software. These products 
are modified media servers or features within a media server that allow you 
to trigger and manipulate movies, images, and other graphic images from 
your lighting console. The console can then use a small number of DMX chan- 
nels to trigger the pixel mapping software, which in turn processes the video 
information into DMX values. By assigning each pixel of an image to a portion 
of a DMX fixture, the software then sends the correct DMX values to the repre- 
sented “pixel” on stage to create the necessary colors (see Figure 8.1). 
Imagine programming an array of 500 LED fixtures (three DMX channels 
each) and the LD asks you to program a spinning blue wave through a striped 
red and green field! If you tried to program this via individual DMX parameters, 
you would go crazy before a third of the way through. However, if you could 
just select the proper movie file and adjust its location within the pixel map, 
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FIGURE 8.1 A pixel mapping screen and the live stage. 


then both you and the LD would be free to move on to further cues in a much 
shorter amount of time (and with no headaches). 

Pixel mapping software is also available directly from a few automated 
lighting consoles. Nevertheless, this still requires the console to generate and 
process large amounts of additional DMX data, which could instead be 
“farmed” out to a specialized computer. Moreover, you may not want to 
have 500 additional “fixtures” in your console just for the upstage curtain. 


MAKING IT EASY 


LED lighting adds energetic and colorful imagery to any production. As long as 
a programmer is familiar with the various types of LED fixtures and the unique 
requirements of each, the programming can be fun and easy. Most of the 
programming is no different than with any other fixture type. Take care 
when patching and creating groups to ensure quick selection of the proper 
units. A good understanding of additive RGB color mixing as well as the 
unique parameters of LED units will prepare any programmer for working 
with LED fixtures of any type. 
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Almost all automated lighting consoles are capable of some form of networking. 
Use of networking within the lighting industry is already commonplace, and it is 
important for a programmer to be familiar with the various uses he or she 
will come across. While every console manufacturer implements networking 
in unique methods, they all accomplish similar primary goals including multi- 
user, backup, distributed processing, DMX distribution, visualizer and media 


server connectivity, and remote access (see Table 9.1). 


TABLE 9.1 Console Networking Categories 
Type Purpose 


Multi-user Multiple programmers 
on one show 


Backup Failsafe fall over 
Distributed processing Output expansion 

DMx distribution DMxX over Ethernet 
Connectivity Visualizer or media server 
Remote access Remote focus 


Protocol 


Console specific 


Console specific 
Console specific 


Console specific or 
industry standards 


Console specific or 
industry standards 


Console specific 
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NETWORK SETUP 


Of course, every console will have its own distinctive screens and methods for 
network configurations. Before you can configure devices to connect to, it is 
essential to understand the purpose and goals of the networking. As described 
above, there are several purposes for console networking. 


NETWORKING BASICS 


Several good books and many websites detail the specifics of computer networks 
for use in the entertainment industry. These sources are excellent for learning 
about IP addresses, DHCP servers, and general network configurations. The 
automated lighting programmer should be familiar with the various types of con- 
figuration possibilities and have a basic understanding of how the devices con- 
nect. One highly recommended text is Rock Solid Ethernet by Wayne Howell. 
Generally speaking, a programmer will need to configure a network to 
either operate through unique IP addresses for each device (similar to DMX 
address of fixtures) or make use of a DHCP server or switch. DHCP means 
Dynamic Host Configuration Protocol and is a management system that automa- 
tically assigns IP addresses to devices found on the network. Many consoles can 
act as a DHCP server; many Ethernet switches have them built in as well. DHCP 
configuration is the simplest type of network setup. You basically set all devices 
to listen for their IP address (except the server or switch), and BOOM! Everything 
is negotiated automatically. You do not need to be concerned with IP address, etc. 
Once the devices are configured, they should begin to communicate without 
further assistance from the programmer. Each specific networking feature has 
its own set of characteristics, which the programmer will handle as needed. 


MULTI-USER PROGRAMMING 


Networking of consoles provides the ability for multiple programmers to work 
simultaneously on the same show file. Typically, each user can log into the 
show file and then access various portions of the rig. The primary console is 
usually the server, and all other devices log into this server as a client. 

The console type will dictate the exact network functionality that is allowed. 
For instance, one type of console allows for “worlds” where each console has 
access only to the fixtures, cues, and parameters marked as part of a certain 
world. In this case the programmer cannot adjust the elements not in his or 
her world. This can be very useful, as one programmer can be working with 
automated fixtures and another with digital fixtures. There is never a chance 
of either programmer accidently grabbing the other’s fixtures. At any time, 
users can switch or combine worlds to gain more control of the rig. Other con- 
soles behave differently by allowing each user total control of the entire rig at 
all times. In this case, users must coordinate with each other to ensure that they 
do not stomp on each others’ work. 
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In a completely different manner, some manufactures follow a more tradi- 
tional “network user login” scenario. With this type of setup, one user is 
considered the administrator and can assign levels of “security” to each user 
account. As each person logs into the system, their preferences, fixtures, and 
other show elements are presented to them. They do not have access to anything 
other than what is assigned to them by the administrator. 


NETWORK BACKUP AND FAILOVER 


Networking with automated lighting consoles also provides the ability to utilize 
additional consoles on the network as a backup to the primary console. As cues 
are recorded and the show file changes, it is simultaneously stored on each con- 
sole’s hard drive. In the event of a catastrophic failure of the primary console, 
the secondary console will automatically take over and continue the operation 
of the show. Hopefully, this is a seamless process that allows for only a small 
amount of distraction on stage and at FOH. Once the afflicted console is 
restored to service (rebooted), it can function as the backup to the current 
primary console. 


DISTRIBUTED PROCESSING 


Another common function of networking with automated lighting consoles is to 
provide additional DMX processing. As shows become more and more complex, 
they often require large numbers of DMX universes. It is not uncommon for a 
production to use thirty or more DMX universes. No console can process this 
many universes solely with the computer components within the desk. Console 
manufacturers have adopted the system of distributed processing to solve this 
problem. Individual network devices capable of processing console information 
and creating DMX output can be connected to expand the amount of DMX 
universes supported by the console. For instance, by connecting processors to 
one manufacturer’s system, you can add sixteen universes per processor. With 
just ten of these boxes, you can quickly have control of over 160 universes of 
DMxX from a single console! Manufacturers are also looking ahead and enabling 
most of their processors to output not only DMX, but also many industry 
Ethernet protocols. 


DMX DISTRIBUTION 


DMX output from automated lighting consoles used to be limited to standard 
5-pin XLR cables. However, it is now common to use a networking protocol 
such as Art-Net, Pathway, E1.31, or ETC-Net to transmit multiple DMX uni- 
verses over an Ethernet cable. When configured, you can send one wire from 
your desk into a network to distribute the DMX data all over a venue or stage. 
At any point on the network, you can connect a node to convert the data back 
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to a standard DMX 5-pin XLR output. In some cases, fixtures can directly accept 
these protocols without the need for any XLR connections. In either case, you 
will need to assign the universe to be used at each node or fixture. Once config- 
ured, DMX distribution via Ethernet is a very useful tool allowing for large 
amounts of DMX data to be moved around a production with ease. 


CONNECTIVITY 


Automated lighting consoles are often connected to visualizer systems for pre- 
programming purposes. Early on, consoles had to output DMX via an XLR 
connection, then this had to be input via an exclusive method to the visualizer. 
In recent years, manufacturers have come to use Art-Net or proprietary proto- 
cols to directly connect consoles and visualizers via a simple Ethernet connec- 
tion. With this type of networking, the console and visualizer send information 
back and forth to create the overall user experience. In many cases this includes 
patch information, fixture selection and positioning, as well as DMX values. 

Additionally, console manufacturers are using connectivity with digital 
lights and media servers to receive thumbnails of content, playback, and 
other information. This then allows the console to display these items to the 
programmer to aid in content selection or other specific digital parameter adjust- 
ments. By allowing direct, two-way communication with media servers and 
digital lights, the industry has greatly expanded the possibilities for the digital 
lighting programmer. 


REMOTE ACCESS 


Usually automated lighting console networking occurs via network cables. 
Wireless networking of console-to-console data can be unstable for show situa- 
tions; however, wireless networking is commonly used with remote focus 
devices. In its simplest form, a wireless remote is just another multi-user device 
logging into the main show file. Usually a custom graphical user interface 
(GUD) provides specialized controls for the handheld device. Since consoles 
do not have wireless switches built in, you will need to connect a wireless 
base station or switch to the console’s network. This can then transmit the 
console protocol to any wireless device capable of receiving the signal. As 
with any wireless network, security is very important, as you do not want 
any lighting enthusiasts to log into your show unexpectedly. 

Wireless remote focus devices allow two-way communication with the 
lighting desk. Quite often you can accomplish most functions that are on the 
console. Various devices can function as remotes, including purpose-built 
remotes, tablets, laptops, and cell phones. It is important for the programmer 
to be aware when a remote is connected to a console, as it provides additional 
input to the console. In many cases, the programmer can log off remotes or 
disable them completely directly from the console. 
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RDM AND WHAT IT MEANS TO YOU 


Remote Device Management, or RDM, is a fairly new concept for automated 
lighting (as well as any DMX-controlled item) that provides configuration, sta- 
tus monitoring, and management of DMX-512-based systems. Although it is 
not a networking protocol per se, it is important to understand how this commu- 
nication protocol functions with lighting equipment. In simple terms, it is a 
method of allowing devices (lights and consoles) to communicate with each 
other. This can eliminate the need for patching and configuring of fixtures. Ima- 
gine in the future that fixtures will just be plugged into a data line and connected 
to a console, and then the programmer will simply press a “configure system” 
button. With this single action, the console will automatically address the 
fixtures and it will automatically associate the proper fixture libraries with 
the respective DMX addresses. In addition, monitoring information such as 
lamp status and fixture errors can be reported back to the console. 

Without RDM, DMX communication occurs in only one direction: data tra- 
vels from the console to the fixtures. RDM allows the fixtures to send data back 
to the console using existing DMX cables and systems. It is a bidirectional pro- 
tocol that communicates on pins 2 and 3 ina DMX cable. The protocol provides 
for a method of uniquely identifying every fixture and device connected to the 
data link, then a list of GET/SET commands allow a controller to query a fixture 
or device for information and change the settings. RDM does this by interleav- 
ing small data packets in between the normal DMX-512 data. RDM-compatible 
fixtures and consoles utilize a unique message within the DMX data (a DMX 
start code), which prevents older, non-RDM-compatible devices from being 
confused by the new bidirectional communication. 

RDM is quickly catching on in our industry, as many manufacturers are now 
including it within their fixtures. Some lighting consoles have even begun to imple- 
ment controls for the programmer to use RDM capabilities. However, there is a 
catch; most existing DMX splitters in the industry were not designed for signals 
traveling in the wrong direction. Fortunately, several new DMX/RDM splitters 
and other devices that are RDM compatible have recently been introduced to the 
market. These items are built to function within the standards of RDM. It is impor- 
tant to always check if all devices on a DMX link are RDM compatible. 

Remote Device Management is well on its way to becoming commonplace 
within our industry. I find it exciting to think of pressing a button on my console 
and having it configure and address the entire lighting rig. Imagine the crew time 
and troubleshooting that will be reduced. While it will take time for every light- 
ing rig to be full of RDM-compatible gear, that time will come eventually. 


E1.31: THE NEW FRONTIER 


RDM is not the only new standard taking the lighting industry by storm; E1.31 
is also starting to emerge. In its simplest form, E1.31 is an ANSI standard pro- 
tocol that sends a large number of DMX universes over Ethernet. E1.31, cleanly 


100 Chapter | 9 The Age of Networking 


put, is “DMX over Ethernet” because this protocol allows the transfer of many 
universes of DMX-512 data over Ethernet networks. It sends the same data as 
DMX but uses standard TCP/IP networks. You might think, “I already have 
Art-Net, so why do I need E1.31?” Well, Art-Net was created as an open 
“DMX over Ethernet” protocol due to the fact that many manufacturers were 
creating their own proprietary protocols for the same purpose. Art-Net has its 
share of problems and limitations, and E1.31 was created to be a more robust 
and easier to use DMX over Ethernet standard. Additionally, E1.31 was 
designed with simplicity in mind and requires a minimal amount of processing 
power for devices that support it. 

Additionally, E1.31 supports sending an incredibly large number of uni- 
verses of DMX data over a single Ethernet cable. Each universe is distinguished 
by a universe number and is sent on a distinct IP addresses. Once a fixture or 
device knows which universe it is interested in, it automatically knows where to 
listen to receive its data. With most modern lighting consoles, an automated 
lighting programmer is likely to find that their console supports E1.31 output. 
This means that with some console configuration, your console can output 
DMX data over Ethernet to other devices by making use of E1.31. A single 
Ethernet cable from FOH could send hundreds of DMX universes to a stage 
or all around a permanent installation. 

Automated lighting programmers will find E1.31 easy to use, as it basically 
is a simple communication method of the well-known DMX-512 protocol. No 
changes to programming procedures or methods are required. In addition, the 
ESTA standards committee is working to expand E1.31 to include RDM 
capabilities. This newest Ethernet protocol is named E1.33 and provides the 
same bidirectional capabilities as RDM on a standard DMX cable. 


EASE OF USE 


While networking may at first appear daunting to many, it is nothing to be 
feared. With the exception of a bit of configuration, networking with lighting 
consoles is rather transparent to the programmer. Once the console and network 
devices are configured and working together, the programmer is free to program 
as usual. By providing various functions such as multi-user, DMX distribution, 
and connectivity, networking simply expands the range and capabilities of a 
lighting console. Be sure to study the user manual of the console system in 
use to learn the specific setup requirements for each console and device. 
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Automated lighting programming can be applied to many different types of 
productions. From theatre to concerts to permanent installations, the variety 
of genres available is practically endless. One of the greatest joys for an 
automated lighting programmer is knowing that every production is different. 
Just as each production presents unique challenges, there are exclusive 
programming concepts and techniques applied to each. Many of these ideas 
can cross over between production types, thus making all equally important 
to an automated lighting programmer, no matter what the production type he 
or she is involved with. 


STRUCTURED AND CORPORATE THEATRE 


The roots of any live performance lie in the theatre. Since before early Roman 
periods, humans have been performing in various venues. The popular theatre, 
as we know it today, evolved over thousands of years with various lighting 
methods. Modern theatrical productions often incorporate automated lighting 
technology into the lighting design. In addition, many corporate events 
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FIGURE 10.1 Structured and corporate theatre productions have unique requirements. 


(business meetings, sales promotions) follow a similar theatrical structure. 
Automated lighting programming for the theatre requires special procedures 
to ensure a highly repeatable production (Figure 10.1). 


Organization 


The very nature of a play or musical requires a structured list of lighting cues. 
Because there are usually many performances, every element of the show requires 
perfectly repeatable execution. Usually the rehearsal and preproduction periods for 
theatrical productions are much longer than for other types of productions. During 
this time, all departments involved will perfect and hone their contributions to the 
production. For the automated lighting programmer, this can be a very tedious 
time. A scene may have only one establishing lighting cue, then after forty 
minutes of acting, a blackout at the end. The scene might be rehearsed for days 
on end without making any changes to the lighting look. The programmer must 
endure the rehearsal process, yet be ready to make any changes as soon as needed. 

The cue to cue organization requires the programmer to maintain order 
while also ensuring efficient playback. Mark and block cues are essential to 
an automated lighting programmer working on a theatrical production. Good 
organizational skills and descriptive labeling of cues, palettes, and so on aid 
the programmer’s effectiveness. At any given moment the LD might request 
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“a washlight pointing stage right in deep blue.” The programmer must be aware 
of fixtures currently in use and/or preparing for use (marked). Only then can the 
programmer make an educated decision as to which fixture to add to the cue. 
Once adding the fixture to the current cue, the programmer may need to 
look back and mark the fixture prior to its use. In addition, the fixture will 
need to be added to any blackout cue for the scene. Usually the LD will simply 
make the request to add the fixture to the cue, and it will then be up to the 
programmer to automatically build the mark, block, and blackout cues. 
A good programmer will accomplish these tasks without the LD ever needing 
to make a request to do so. 


Conventionals 


Theatrical lighting usually includes both conventional and automated program- 
ming. Some productions will use a specific console for each type of lighting, 
while others will control all lighting from one console. If both conventional 
and automated lighting will be programmed on one desk, then the automated 
lighting programmer needs to prepare for conventional programming. Quite 
often an LD will spend great lengths of time adjusting the intensity values for 
conventional lights. The programmer should be prepared to adjust levels quickly 
and easily. Groups, palettes, and quick intensity functions become essential tools 
for the programmer. Many designers also find it useful for the programmer to 
repeat tasks to them as they happen. This way the LD can keep his or her eyes 
on the stage looking for the level changes. For instance, when asked to bring a 
conventional channel down 10%, a good programmer will do so quickly and 
respond by stating the new value. For example, he or she might say “at 60.” 
Then the LD will have a reference to the value and can make another requested 
change if needed. With the next change the programmer will again state the new 
value (“at 50°’). While this small function can be very helpful to many LDs, it can 
be an annoyance to others. Be sure to consult with your LD prior to calling out all 
level changes. After programming several productions, many programmers find 
that repeating intensity level changes, color or position palette names, and other 
functions to the LD becomes habit. Luckily, many designers appreciate this 
automatic feedback given to them by their programmer. 


Dual Consoles 


When adding automated lights to a theatrical production, numerous designers 
choose to have a desk for each type of lighting (conventional and automated). 
This allows for multitasking, as both programmers can be working on different 
elements of the same cue simultaneously. In this scenario both programmers 
must ensure that they use the same cue numbers and structure. For example, 
“lighting cue 28” should reference the same point in the show on both consoles. 
If the conventional desk has a cue 30 and there is no need for a cue on the 
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automated desk, a blank cue should be inserted to maintain uniformity between the 
two consoles. This will guarantee a consistent cue structure for the production. The 
LD or stage manager will then be able to call “go cue 30” and both console opera- 
tors can trigger a cue (without having to check for its existence first). 

Some productions will require two different consoles for programming and 
then utilize only one operator for playback. With two consoles in use during 
programming, cue creation occurs much faster. The conventional programmer 
can slowly adjust levels with an LD, while the automated lighting programmer 
is busy building a complex chase for the same cue. Once the show is 
programmed and rehearsals are complete, two console operators may not be 
desired. There are several choices for how to combine the playback capabilities, 
allowing one-person operation. The first is to have one console trigger the other 
via MIDI or MIDI Show Control (or other triggering methods). The operator 
will then simply play back cues from one desk, which will in turn send match- 
ing triggering information to the second desk. If both desks are programmed 
with an identical cueing configuration, then all cues should remain perfectly 
synchronized. Newer consoles allow multi-user programming via networking. 
With this method, several programmers can log into the same show file and 
program as needed. Then the “extra” consoles can be removed, and all the 
data is stored on the primary console and ready for playback. 

Another method for reducing the number of consoles required for playback 
is to capture the data from the conventional console into the automated lighting 
console. Many sophisticated lighting consoles have the ability to capture and 
record DMX values. After both consoles are fully programmed, the DMX 
values output by the conventional desk will be recorded into the automated 
lighting console on a cue-by-cue basis. Only DMX values are recorded, so 
the automated lighting programmer will have to reprogram any timing informa- 
tion. Once all the cues are captured and recorded into the automated lighting 
console, all playback and future editing will take place from this desk. 


Prepared Theatrics 


Automated lighting programming for theatrical productions is as fulfilling and 
challenging as any other genre of lighting. Many times fixtures are used simply 
as repositionable lighting fixtures and the audience may never notice the 
automation features. Other productions will make full use of obvious fixture 
movements and output changes. Regardless of the uses, the most common 
element of theatrical type productions is a structured cueing method. 


CONCERT TOURS 


Concert tours are a driving force of the automated lighting industry. Almost 
every musical concert of any genre employs the use of automated lights to 
enhance the production and save time. There are many techniques used when 
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FIGURE 10.2 Concert tour programming can be very challenging. 


programming concert tours that are unique to this type of production. An 
automated lighting programmer must be aware of these requirements when 
programming for any concert tour (Figure 10.2). 


It Is All About the Music 


The very first thing you must do, as a programmer of a musical concert, is to 
listen to the music. Then listen to it again. Keep listening to it until every 
beat, every change, and every nuance (no matter how subtle) is ingrained in 
your mind. With a good understanding of the music, you will be prepared to 
understand the goals and desires of the LD. Usually the LD will have discussed 
his or her concepts with the artist(s) prior to your programming session. Listen 
to the LD’s ideas and then try to apply them to the music. You must always 
remember that in most cases the concert is about the music and not a light 
show. The lighting is there to enhance the overall production, not to override 
it. After all, the crowd paid money to hear the artist, not watch your lighting 
programming. 


Before You Program 


The first thing you need to consider when preparing to program for a concert is 
who will be operating the console. Sometimes you will not only program the 
show, but also tour with it, operating the desk at every performance. However, 
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if you are hired to simply program the desk and leave it for the LD or another 
person to take on the road, then there are many special considerations you 
must make. 

When programming a show for another person to operate, you must be very 
conscious of your organization and labeling. If you label all the cues with 
strange acronyms that only you understand, how will someone else be able 
to take over for playback? 

Prior to the actual building of cues for your concert, you will need to set 
up palettes (sometimes called presets or memories) in the desk. These are 
references to quickly select common positions, colors, and so on to be used 
when programming. In addition, if your cues refer to the palette instead of actual 
values, then you can update the palette values and the cues will simultaneously 
update with the new parameter information. Touring shows survive on position 
palettes. Each day the lighting rig may not be hung in the exact same position, 
height, and offset from the stage. The operator of the desk must spend a good 
portion of the preperformance time refocusing each light to the correct position 
for that day’s configuration. For example, if the front truss is | foot higher and 
2 feet farther offstage than in the rehearsal space, then all the positions the 
fixtures point to will be incorrect. However, by simply updating all the position 
palettes with the correct values for the new configuration, the cues will play 
back as they were programmed. 

When setting up your position palettes, you do not want to make hundreds 
of positions. Doing so will only result in more work on site each day. Most 
concert tours arrive at a venue early in the morning and build the lighting rig 
and stage. By the time everything is operational, it is usually mid-afternoon. 
The operator may have only a few hours to refocus all the fixtures’ position 
palettes. Care must be taken during programming to minimize the number 
of palettes, while allowing for a multitude of looks throughout the show. As 
you are programming the show, you must always take into consideration the 
daily setup time of a tour. 


Cue Building 


When you and the LD sit down to begin programming the first song, you will 
probably listen to several versions of the song. Musicians often play music 
differently live than on their CD. If you program to a studio-mixed CD and 
time your chases and transitions to match the tempo, don’t be surprised when 
the live version is different. 

Each musician is different; the same is true for LDs. Sometimes you will 
build a very structured show with a cuelist (sequence or stack) for each song. 
Other LDs prefer to have a layout of buttons and faders, so they can “create” 
lighting looks as the band plays. Depending on the type of music and the 
LD’s preferences, you will often program concert tours in different ways. 
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As stated earlier, it is important to know whom the operator will be and set up 
the console accordingly. Remember, there are no rules and anything goes. 


Standard Operating Procedure 


Of course, there is no one method for programming a concert tour; however, 
there are some common procedures that are often used. Generally, an artist 
will change the set list on various nights of the tour. The band does not always 
want to play the same songs. Hopefully, you have programmed cues for all the 
songs you think they will ever play. Then when you are informed each night of 
the songs to be played, you can simply reorganize your show to accommodate 
that evening’s selection. The order of the songs each night is usually called a set 
list. The set list will have the song names and breaks or encores listed. This does 
not mean the band will actually follow the list, but it gives you an idea of what 
they plan to play at that performance. 

Most automated lighting consoles have a function known as pages. Each 
page will contain a certain number of playbacks with specific cues loaded 
into buttons on the console. Programmers will organize a concert by using 
one page per song. For example, page one might be for “Silent Night” and 
page two for “Deck the Halls.” If the artist has 28 songs in their repertoire, 
then you will need to have a page for each song. On each page, you will 
have cues, presets, and chases that you created specifically for that song. As 
the band changes from one song to the next, you simply change the page on 
the console to prepare for each new song. The console will usually have a 
method to reorder the pages so you can match the set list for each performance. 
In this way you can quickly organize the programming in the desk to match 
the artist’s decision for the set list. 


Every Concert Is Different 


There are no hard and fast rules about programming automated lights for 
concert tours. The great fun is that they are all different. Due to the requirements 
of the show, the LD, and the artist(s), every tour is completely different. There 
is no magic formula for creating the perfectly programmed show, but with some 
consistency you can make the process simple. 


TELEVISION EVENTS 


Many television productions utilize automated lighting to create bold 
movements or color chases. Other programs simply use the technology as 
remotely refocusable lighting sources. Award shows, game shows, and musical 
variety acts commonly benefit from an automated lighting rig. In each of these 
situations, the lighting designer must make special considerations for the 
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FIGURE 10.3 Televised events add a new eye to the situation. 


cameras. When working as a lighting programmer for television events, it is 
essential that these unique requirements are taken into consideration with 
every button press on the console (Figure 10.3). 


The Cameras Are Your Eyes 


The significance of the camera’s point of view to the lighting programmer 
cannot be overstated. The most important thing to remember when program- 
ming for a television show is that the picture on the screen is the ultimate 
purpose of the show. You must not lose sight of this goal when helping to create 
perfect television pictures. One of the most common questions about television 
lighting is: “Do you worry about how it appears to the live audience?” 
Generally, the answer is no, because the live audience for a television event 
basically becomes another element of the set. Again, the goal is to create a 
television show for all the (potentially) millions of viewers, and not a live 
event for the local audience. Everything must be considered based on how it 
looks on television. This can create some problems for the programmer, but 
can also open up some unique possibilities. 

In order to know exactly how the event will look on screen, the programmer 
will require a program monitor. A program monitor will allow him or her to 
see exactly what the viewing audience will see (called the line cut). In addition, 
the programmer commonly will have a second monitor with a video switcher. 
The switcher will allow the programmer to view any of the camera shots at any 
time (regardless of what is on the line cut). By selecting between the camera 
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shots, the lighting programmer will be able to check each shot before the video 
director changes to one on the line cut. When building positions, colors, or cues, 
the programmer needs to watch the monitors to determine how the lighting 
appears on camera. For instance, all the upstage lights fanned out to the 
audience position may look great from FOH, but not even show on camera. 
If the cameras don’t shoot it, then it does not exist. Generally, when sitting 
at FOH programming for a television event, programmers spend 90% of their 
time looking at their television monitors. Many programmers become so 
focused on the screen that they forget they are actually sitting at the event 
they are watching on their monitors. 


Adjusting for the Camera 


Television cameras respond to lighting much differently than the human eye. 
Intensity levels, colors, angles all need to be considered from the camera’s 
point of view. The human eye is very forgiving when it comes to different 
lighting intensities; it has an amazing ability to balance high and low light 
levels. Unfortunately, television cameras do not have the same ability. The 
LD will want to balance all levels so the overall on-screen picture is correct. 
I will not get into the design aspect here, as I am writing about programming, 
but it is important to understand some television lighting basics. The more you 
can understand the designer’s intended picture quality, the better you can help 
create the overall look of the show in a quick and efficient manner. By 
watching the monitors at all times you can determine what lighting elements 
are in the camera shots and how the lighting will affect them. For example, if 
you have a nice gobo wash on the backdrop it might look great in the wide 
shot. However, when the video director cuts to a close up, the background 
of the image might overpower the followspot intensity on the performer. 
You may find that setting the intensity of the gobo wash to 50% will work 
well in both the wide and close-up shots. By anticipating these types of things, 
the initial programming will require much less adjustment when viewed on 
camera. 

The lighting designer will be concerned with the aesthetic appearance of the 
background of the camera shots. The programmer must also take this into 
consideration when building looks. Again, imagine a gobo wash on the 
backdrop. In the wide shot it might appear as the best gobo wash that was 
ever created, but in the close-up shot there is nothing visible in the background. 
You might have to move some fixture positions around to ensure that the 
background of the close-up is perfect (without destroying the look of the overall 
wash). When lighting set pieces, take care not to waste time lighting pieces that 
will never be shown (or lighting them from the wrong angle). Television crews 
have some amazing technology in their bag of tricks. They often use jibs 
(a camera mounted on a crane) and Steadicams (a camera mounted to a 
human). These types of cameras will shoot from angles you never thought 
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of. By paying attention to what the video director decides to shoot in rehearsal, 
you can determine what needs to be lit. 


Colors and Their Temperature 


Television cameras must be balanced to a specific color temperature. This 
setting will determine exactly how colored lighting will appear on camera. 
Most automated lighting fixtures use lamps with a high color temperature of 
around 6500K. Usually, but not always, television shows are balanced to a 
low color temperature of around 3200K. This will result in colored lights 
appearing different on camera than to the eye. An open white fixture will be 
blue on camera. In addition, all other colors will have a bluish tint. Pure 
magenta takes on a purple color when viewed on screen. Understanding 
these differences and taking them into account when building palettes and 
cues is essential for good television lighting. Also, you must be constantly 
thinking in terms of the television colors and not the eye colors. For example, 
if the LD asks for a pale lavender wash, you would actually bring a light pink 
color into the fixtures (on camera, however, it will look lavender). Over time 
you should be able to predict how certain colors will appear on camera and 
will be able to build palettes and cues before your monitors arrive. 


The Magic of Television 


As I have stated, you must consider what the camera sees when programming 
automated lighting for television productions. Because the camera’s view is the 
main perspective for everything you do, this can present new advantages over 
programming for the live audience. Remember, if the camera does not see it, 
then it does not exist. You can actually use this unique television feature to 
your benefit. For example, I was programming a televised ice skating competi- 
tion and did not know the order of the skaters’ routines. I had built cues for 
each, but did not have clean transitions from one skater’s end look to the 
next one’s beginning cue. At the end of each routine, the video director 
would cut from a shot of the ice to a close-up of the skater receiving their 
score. As soon as I saw this change on my line-cut monitor, I would change 
the lighting look on the ice. Then after the skater received his marks, the 
video director changed the shot back to a nice new look on the ice. The cameras 
did not pick up the “messy” transition from one ice look to another, although 
the live audience did see it. Often during awards shows the stage lighting 
will change while the cameras are on the presenters. 


The Magic Box 


Television is a unique medium that presents unique challenges to an automated 
lighting programmer. It is often very difficult for a programmer who works 
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primarily with live events to switch over to television programming. Training 
yourself to focus your attention on the monitor and not the stage can be 
difficult. Just remember that the most important view is that of the camera. 


MUSIC FESTIVALS AND ONE-OFFS 


So you have been hired to program for a three day music festival. What do you 
do? If it is like most festivals, you will be given a plot and very little other infor- 
mation (Figure 10.4). 

The first thing to do is to gather as much information as you can. Oftentimes 
this might mean going to the website for the event to see what acts will be on 
your stage. Now try to listen to some music from each of the bands to get a 
good understanding of what you are up against. I have seen some shows that 
will go from a DJ, to rap, to rock, to top-40, and then to hip-hop. You need 
to be prepared for anything. 


Organize Your Data 


Most festivals are so big that many of the details we are looking for in order to 
do our job are just not available. So you might be given a plot (you might even 
be designing the rig), but usually there is very little organization. The first 
concern you should have is your programming time. Consider yourself lucky 
if you get more than one night to preprogram for all 22 acts! So your first 
priority should be to try to gain as much programming time as possible. The 
best way to do this is to organize your needs and see that they are taken care 
of at load in. If you take the time before the show to build the patch and create 
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a plot showing all the addresses, universes, placement notes, and so on, then 
you can shave a few hours off the load in time. I will usually take the plot 
I am sent and add in all the information I feel will be needed and send it 
back to the crew chief. In addition, I will bring six or seven copies with me 
and have them ready to hand out to any crew member who might need it. 

Ask for FOH power as soon as possible. This way while they are building 
the rig, you can make yourself busy by building your new home. Set up the 
consoles, monitors, UPS—you want to be ready to test that everything is 
working correctly as soon as fixtures have power and data. Try to prepare 
as much of your show file as you can prior to the event. I am not talking 
about using visualization to preprogram the entire show (unless they are 
paying for your preprogramming time), but patching a show and building 
some groups and palettes on an offline editor should only take an hour or 
two. If you arrive on site with this little bit of work complete, then you can 
start programming as soon as the rig is ready. 


Programming 


Even if the rig is not complete, begin programming as soon as you can on site. 
Make the most of this time and program with what fixtures you do have. If you 
wait until the rig is 100%, then you will have very little programming time. 
Generally, you will know little to nothing about the bands and their set lists, 
so you need to be prepared for anything. Try to program a page or two of 
looks that will allow you to deal with most situations. For example, you will 
need a few different stage washes, color bumps, audience looks. Do not 
spend lots of time programming very complex effects and chases. You will 
find that while they might look great, it is very hard to work these types of 
things into varied musical acts on the fly. Instead, you might want to build 
things you can trigger manually so that they can work with any tempo. 


One Approach 


Every programmer will lay out his or her console differently, but here is a 
general idea of how I do it for these situations. I will have about eight bump 
buttons of color bumps, usually different colors for each fixture type stored 
in one button. Next I will have shutter controls where I can blackout fixtures 
by type. Then some ballyhoos and flyouts by type, and strobe chases by fixture 
type. Another 8 to 10 playbacks will be devoted to what I call “rock looks.” 
These are big stage looks using all fixtures. When a song begins, I can play 
a rock look while blacking out the hard edge fixtures. Then for the chorus 
I can switch to blacking out the wash fixtures and see only the hard edge. 
On a downbeat I can switch back to the wash lights, with a different color 
while flying out to the audience, then restore to the hard edge in yet another 
color. This entire time I am playing from the one “rock look” but modifying 
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it live and to the beat via my bump buttons. This simple approach not only uses 
the benefits of tracking, but also allows me to keep the show fresh and vibrant 
throughout the different acts. 

My approach does not allow me much time to rest during the show. I have 
seen operators who like to press one or two buttons during a song and not make 
many changes on stage. When on touring productions you can take the time to 
program a show so that a single GO button can be pressed at key moments, but 
with a festival gig this is usually not possible. Some slower songs might allow 
me a moment or two to have a drink, but generally my fingers are flying as long 
as the band is playing. The reasoning for my method is because with no rehear- 
sals, there is no way to synchronize the lights to the beat, unless you play along 
live. In addition, this provides the best light show, as it continually works with 
the music on stage. 


Visiting LDs 


Sometimes a band will arrive with their own LD, which can lead to four differ- 
ent scenarios. If you have a common lighting console, they may load in their 
touring show, change the patch, and simply update positions. In other cases, 
the LD will arrive the day before and ask to spend a few hours after the 
gates close to program his or her specific cues (probably using your positions 
and groups). Other LDs will wait until the show and get on the headset to 
call followspots and call cues to you, with you using whatever you have in 
the desk. This is where you will need common washes, colors, strobes, and 
so on. In the final scenario, the LD will simply walk up to your desk and run 
it using whatever you make available. Then you can just sit back and watch the 
magic of someone else running your cues. 


Fun for All 


Festival gigs can be tremendous fun and lots of work. They give you a chance 
to work with many acts and varied musical types in a short amount of time. 
These productions can be a great place for creative experimentation and 
programming experience. Remember to keep it simple and have fun, and you 
will get through all the acts with no problem. 


ARCHITECTURAL INSTALLATIONS 


Automated lighting is often used not only on stages and in studios, but 
also for permanent architectural installations. Exteriors of buildings, bridges, 
monuments, retail store interiors, movie theatre lobbies, and even private 
homes are often enhanced through the use of automated lighting. Most light- 
ing manufacturers have responded to this demand by creating fixtures and 
consoles specifically for this market. Just as many of the fixtures are unique, 


114 Chapter | 10 Programming Genres 


FIGURE 10.5 Architectural installations can run for many years. 


the programming of an architectural installation requires special techniques 
and procedures not commonly used in other programming applications 
(Figure 10.5). 


Where Is FOH?2 


The placement of the lighting console for programming purposes is an 
extremely important decision. You will need a vantage point where you can 
see the majority of your lighting surface. In fact, you might require multiple 
programming positions. For example, if you are lighting a building on all 
four sides, you might need four programming positions. Each of these positions 
will need a specific setback distance that allows a wide view of the building. 
Power and data will need to be accessed at each of these locations, as well 
as a form of communication with your technical crew. Programming a large 
surface may require that your FOH position is hundreds or thousands of feet 
away. Modern lighting consoles can use fiber-optic or wireless communications 
to allow control from virtually anywhere. 


Look at the Time 


The majority of permanent architectural lighting installations run in a stand- 
alone mode. The console is usually programmed so the fixtures turn on and 
off at a preset time. In addition, cues may need to be triggered at specific 
times and/or dates. All this programming will usually fall to the automated 
lighting programmer. Most consoles have a clock allowing for cue triggers at 
specific times of day or days of the week. Some desks also include an astronom- 
ical clock function. When you input the location of the installation via latitude 
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and longitude, the console will calculate individual sunrise and sunset times for 
every single day. These calculations are very useful, as they can be used with or 
without an offset to trigger lighting events. 

In addition to programming the lighting cues, you might need to enter 
additional data to turn the fixtures on or off. Most fixtures have a control 
channel that allows for shutdown and startup of the fixture. If you build a 
cue to shut down the fixtures at 5 a.m. and another cue to start them up at 
6 p.m., then you can use clock triggers to automate the fixture usage. Sometimes 
the lighting installer will simply use a timer to enable or disable power to the 
lighting fixtures at a specific time. You will need to be aware of this, as it 
might affect your programming period. There is nothing worse than program- 
ming all night long only to have power disabled to the fixtures at 4 A.M. 
(just when you are nearly finished). 


User Interactions 


Many architectural installations will simply run as programmed and require no 
interaction from the users. This is a good thing, as there is usually not a lighting 
professional on staff at the location. Many times the automated lighting is 
looked at by the staff no differently than the parking lot or interior lights. 
However, even if no user interaction is expected, you should plan accordingly. 
First Gf you are able to), lock the console functions with a password. Make 
backups of the show file and store them on the controller’s hard drive, or at 
some location near the controller. This way, if something goes wrong, you 
can point someone to a backup copy of the show file(s). In addition, you 
might create manually triggered functions to override the normal operation of 
the lighting show. For example, there might be a need to turn fixtures on or 
off other than during the scheduled hours. Additionally, the staff might want 
to override lighting looks on specific holidays (for example, red for Valentine’s 
Day). If you have the time, it does not hurt to add these additional cue options 
into the programming. 

More complex installations may interact with additional show control 
computers. These systems will trigger the lighting console (via Ethernet, 
MIDI, or SMPTE) as needed. You will need to coordinate with the show con- 
trol specialist to determine what type of interaction is needed. Furthermore, 
some installations may require advanced network setups allowing direct access 
of lighting control from a secure web page. 


Maintenance 


As stated earlier, most architectural lighting installations generally do not have 
specialized lighting personnel on staff. This can be very frustrating when, for 
example, you return to the installation at a later date to find fixtures with burned 
out lamps or broken electronics. While there is little you can do to resolve 
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hardware problems, you should try to minimize problems due to programming. 
For instance, if you created cues to strike and shut down the lamps of the 
fixtures, you should confirm they are working correctly. No one may notice 
if the fixtures are burning their lamps all day, but this will reduce the lamp 
life of the fixtures and possibly cause overheating problems. Before completing 
your lighting programming, you should verify that your cueing is working 
as expected. In addition, you might put in a secondary shutdown or startup 
command (ten minutes after the first), just in case something goes wrong. 

Because these installations are usually not supervised by lighting 
professionals in the same manner as a normal production, you should program 
in additional safeguards. For example, you could find a moment halfway 
through the evening to send a reset command to the fixtures. This can help 
to ensure that all fixtures are properly calibrated and working correctly. Instead 
of resetting them all at the same time, you might do it in three groups of fixtures 
to minimize the distraction. Small details such as this can greatly improve the 
overall life span of an architectural installation. 


Permanent Joys 


Sometimes architectural installations can be frustrating to program due to harsh 
conditions (programming lighting for a bridge spanning icy waters during the 
winter) or strange hours (entering a shopping mall as everyone else is leaving). 
However, these installations offer a huge reward that is often not available with 
other types of productions: longevity. An installation will often remain active 
for many years and be seen by millions of people. It is very satisfying to return 
to an installation after five years and see your programming still in action. 
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As the programmer of the show, you are generally not responsible for the 
working order of the fixtures. However, there are many times when it is 
necessary for you to troubleshoot to help the technicians determine the exact 
nature of the problem. In addition, since you are the one “driving the car,” 
all data-related problems always point back to you and the console. For exam- 
ple, if a light is acting sporadically and randomly blacking out, this could be 
related to data lines, the console, the fixture itself, or even the programming. 
What follows are some common problems and troubleshooting procedures 
that you will be faced with as a programmer. 


COMMON PROBLEMS 


The first step in solving problems is recognizing that you have a problem. 
Problems can be obvious, such as the lights not responding to the desk at all, 
or subtle, such as the fixtures not accurately hitting the same spot twice. Some- 
times a fixture might flicker or shake as if it has a nervous twitch. Other times 
the lights might seem to be running cues from a different show. Whatever the 
problem, you need to find the cause and repair it quickly so programming time 
is not lost. 


Data Problems 


A good way to think of your data and data lines is as water in water pipes. If 
your pipes have leaks or clogs, then the water will not get through to the faucet. 
Generally speaking, it is always a good idea to have a terminator on your data 
lines. A terminator is a resistor on pins 2 and 3 built into a male XLR connector 
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(check your fixture’s manual for exact specifications). Lack of termination can 
cause all kinds of wacky problems. Using the water pipe analogy, termination is 
like putting a plug at the end of a water line to maintain good water pressure. If 
the plug is not in the line, all the water spews out the end of the pipe and 
reduces water pressure. Lack of DMX termination can cause fixtures anywhere 
in the data line to act erratically. For instance, fixtures might flash on and off or 
oscillate their color wheel, or even not respond at all. Sometimes it might be just 
one fixture, sometimes more. If you have multiple data lines from your console 
or from a data splitter, be sure to terminate each DMX line. 

The DMX-512 specifications indicate that the data line run should be no 
more than 2500 feet. If you have extremely long cable runs, you might see 
problems similar to lack of termination. In addition, fixtures beyond a certain 
point in the data line may not respond to the DMX. A simple way to solve 
this problem is to put a DMX splitter in the line, as most DMX splitters also 
amplify the signal. 

Care should be given to the DMX data cables. If the cables have a break 
or cut in them, some fixtures may not work. I have actually seen a data cable 
that had a break in pin 1. The hard edge fixtures in the rig operated correctly, 
yet the wash lights would not respond. It turned out that the hard edge fixtures 
could operate without this part of the signal, while the wash lights could not. 
A faulty data cable usually causes fixtures beyond that cable not to work and 
is pretty easy to find. A short in a data cable, however, can be more difficult 
to find. It is always a good idea to carry a DMX tester of some type with 
you. There are very simple testers built into XLR connectors and very complex 
testers made to work with personal digital assistants (PDAs). As long as we are 
talking cables, with DMX it is a bad idea to make a Y cable to turn one run 
into two. Twofers are commonplace with electricity, but should never 
be used with data. DMX splitters are commonly available and should always 
be used to split data runs. 


Console Problems 


If the data lines check out okay, then you could have a problem with your con- 
sole. Console troubles might be due to problems in the patch of your fixtures, so 
first verify that you have the correct settings in the patch and at the fixtures. In 
addition, you might need to use your DMX tester to analyze the output from the 
console. Most fixtures prefer a DMX refresh rate of around 30 MHz. If your 
console is refreshing at a slower rate, the lights might not behave correctly. 
Many consoles have fuses on the data lines to protect the console from 
power coming down the data lines. If one of these fuses is blown, you will 
not get any DMX output. Also, check with your console manufacturer to 
make sure the version of software you are using does not contain bugs that 
could affect the processing of DMX. New consoles are appearing on the market 
every day, and any of them could have many different types of bugs causing 
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unexpected behavior from your console. If you suspect the console is causing 
the error, try sending DMX to the fixture(s) from a DMX tester or another 
desk and see if the problem continues. 


Network Problems 


The networking era has added yet another layer of complexity to automated 
lighting control and troubleshooting. If your networking equipment is not 
functioning properly, then you will not have control of processors, DMX 
over Ethernet output, or multi-user controls. First you should check all connec- 
tions and Ethernet switches. Then confirm the communication configuration on 
each device to ensure that proper ports, IP addresses, network types are all set 
up. Generally, once a network is set up, configuration changes will not be 
necessary. If a device suddenly stops functioning, then it is most likely not 
due to the configuration. Networking equipment and cables can fail like any 
other device, so backup procedures should be put in place for all lighting 
networks. 


Fixture Problems 


If you are sure that the console is operating correctly and the data lines are good, 
then the problem could be with the fixture itself. The first step to test for a bad 
fixture is to address another fixture of the same type to the same address as the 
fixture with the problem. If the problem now occurs on both fixtures, then you 
know the difficulty is not fixture specific. If one fixture behaves correctly and 
the other still responds poorly, then you need to determine what is wrong with 
the fixture. Notify the lighting technicians that the fixture needs to be repaired 
and let them know what type of problems you are seeing. If you are both the 
programmer and the lighting tech, then you will have to stop programming 
and go fix it yourself. 


Operator Error 


As much as we hate to admit it, sometimes we might be the cause of the 
problem. If a fixture is not responding at all, maybe it has been parked from 
the console or sent a shutdown command. It could be as simple as not paying 
attention to what is currently selected on your desk. For example, if you select 
the “CS truss” group and find the center fixture is not responding, the problem 
could be because you forgot to put this fixture in that group. If a fixture appears 
to be randomly blacking out, maybe the console is telling it to black out without 
you realizing it. I remember one show where I had a fixture that would fade to 
black every minute or so and I could not determine the cause. It turns out that a 
cuelist I built two days before to control the fogger accidentally had a value of 
zero on one cue for this particular fixture. Because the fogger cuelist was 
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“running in the background” I did not immediately think to check it as the 
cause of the problem. The simple fix was to remove the errant value from 
the fogger cuelist. 


Getting Help 


Problems most certainly will occur, and the sooner they can be resolved, the 
sooner you can get back to work. If you are aware of the common problems 
and solutions, you can help determine and solve most of them. When you 
are stumped and are at the end of your resources, there are usually people 
you can call. Our industry is very good about providing technical support. 
Not only most fixture manufacturers, but also many of the lighting suppliers 
and production companies offer 24/7 support. Before you encounter any 
problems, note the phone numbers you might need and carry these with you. 


EMERGENCY PREPAREDNESS 


Imagine this: You are standing at FOH with total control of all lighting in a 
venue filled with a large crowd. You are suddenly told there is a major storm 
outside and a tornado is rapidly approaching. What do you do next? Are you 
prepared for the unknown? Disasters can occur at any time without warning. 
As professional lighting programmers and operators, we must be prepared. 

There have been many major nightclub and other production-related 
tragedies throughout history. Part of the problem in these situations resulted 
from entertainment professionals not being prepared for the unexpected. If 
everyone involved in a production were to maintain a high level of safety 
standards, fewer accidents would occur. I believe there are procedures and 
plans that lighting programmers should consider as professionals to assist in 
these situations. Since I have been involved with this industry for more than 
20 years, I have had some experiences that have taught me valuable lessons. 
However, I still try to prepare for the unknown and be ready to handle any 
situation. 


Be Prepared 


Early in my career, I was running followspot for a country act at an outdoor 
amphitheater when we were told by the LD to lock down our spots and get 
down off the roof ASAP. We then noticed a huge wall cloud approaching 
and heard tornado sirens. Once we got down on stage, we discovered the 
power to the venue had been cut off. The two wimpy emergency lights on 
stage worked only for about 10 minutes. I was shocked to find I was one of 
the few stagehands on the call with a flashlight (two, actually) in my bag. 
Not only did we have to begin load out in the dark, but we also had to deal 
with a hostile crowd that could not leave the venue (the parking lots were 
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flooded with 4 feet of water). Since that event, I have always made it a point 
to have a flashlight in my pocket for every show I am working. In addition, 
I check the batteries periodically and carry a spare flashlight in my bag. You 
never know when something will go wrong, and if anyone should have a 
flashlight at the ready, it is the lighting guy. 


Safety of Others 


As the lighting operator, you are responsible for the lighting inside the venue. If 
there is a major incident in the crowd, you might have to bring up audience 
lights to help emergency personnel. I saw footage of a festival where several 
audience members were crushed by the swelling crowd. In the news footage, 
I could see all the stage lights in open white pointing into the crowd. The light- 
ing operator was extremely helpful to the medical and security personnel. To 
prepare for these types of situations, you should have a “work light” cue 
ready to bring up at any time (during rehearsals and performances). If you 
are in the middle of programming and you hear a loud crash and yell, you 
should be able to instantly access this cue to help ascertain what just happened. 
In the same manner, you need to be sensitive to others who might be working 
while you are programming. If there are technicians on stage and in the rig, you 
might not want to trigger your strobe lights. I am usually very aware of other 
people when working with a large number of strobe lights. Just before I test 
a strobe cue, I often call out, “Watch your eyes, the strobes are about to 
fire.” This way if a technician had been staring right at the center of a strobe, 
he or she will not be blinded (or at least was warned!). 


Personal Safety 


I make it a point to ask for security barricades and personnel for my FOH 
position. You never know who may try to get up to your position. Not only 
will they distract you from your work, but they could also cause problems. 
Even if you are working in a theatre, you will want to ensure that there is 
restricted access to the lighting booth. If your console is set up on a riser or 
road cases, you will want to double-check that everything is locked down. 
Imagine what could happen if the entire FOH was to collapse without notice. 
You should always take the time to confirm that you have a safe working 
environment. 

Even before the terrible events of September 11, we had to deal with 
security checks and bomb searches. Now the threats are much more credible 
and convincing. If you feel a particular event is not secure enough, then you 
should say something or not do the gig. I know of several programmers who 
turned down jobs on New Year’s Eve 2000 simply because they felt the perso- 
nal security risk was too great. In addition, if you notice some other hazard 
(poor rigging, unsafe pyrotechnics, etc.) you need to consider your options. 


122 Chapter | 11 Troubleshooting 


If you accept the danger, you could put yourself and others at risk. You should 
also think about the possibility that you could be held responsible in a court of 
law if you are part of a production involving a major accident. 


The Actor’s Point of View 


Many years ago when I was running the lighting for a production of Annie, 
I made a big mistake. During a performance, I jumped the gun and took a black- 
out early. This resulted in a child actor falling off a riser on the set and twisting 
her ankle. I felt terrible, as I knew that I had directly caused her injury. When 
programming and operating the lighting in a venue, you must consider the 
performers on stage. Walk up on the stage and see how blinding the cues 
you just built are from center stage. You might find that the angles of the 
floor fixtures do not allow the performers to see the front edge of the stage. 
This could lead you to update your positioning to a better angle. In addition, 
consider what the actors are doing. For example, when programming lighting 
for ice skating events, it is common practice to light the ice bright with no 
cues or changes when you expect the skaters to perform jumps. If you were 
to take a cue at the same instant a jump is to occur, it could be disastrous for 
the skater. In the same manner, you should consider the audience’s point of 
view as well. When projecting textures on the walls of a venue you should 
check to see that patrons are not blinded going up and down steps or in and 
out of doorways. 


Safety First 


As professionals in the entertainment industry, we must take responsibility 
for our area of specialization. We should do everything we can to ensure that 
all elements relating to the lighting are the safest they can be and that we 
have prepared for every possible contingency. By imagining the worst, we 
only help to make the show the best it can be. Think of any production-related 
tragedy in history and imagine you were there. If you were standing at FOH 
behind the lighting console at the moment of the disaster, how would you 
have reacted? 


Chapter 12 
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Working as a professional lighting programmer requires many skills beyond 
the programming of lights. The relationship between a programmer and an 
LD is oftentimes more important than how well either one can handle his or 
her individual job. One of the most amazing things in our profession is how 
a group of people who have never met before can come together and make a 
show a success in a short amount of time. The working relationships become 
just as important as the knowledge and skill of those involved. The first 
time we work with a designer, we must quickly determine how he or she 
works, his or her personality, quirks, and so on. Often there is very little time 
to “get to know” the people you are working with, as production schedules are 
too tight. 


PEOPLE ARE PEOPLE 


When atriving at a gig or meeting an LD for the first time, you must remember 
that everyone there has the same goal: to make the show a success. You might 
make a new best friend of the LD and have a great career programming all his 
or her shows. However, you might also find that the LD has annoying habits 
that drive you so crazy that you just want to leave the gig. Of course, you 
will not leave the gig, but you may find that the LD is difficult to work with. 
This is where your relationship skills will be put to the test. If you can learn to 
recognize the different types of LDs and quickly adapt to their lighting style and 
personality, then you will be successful in most situations. Even if you cannot 
stand the person you are working with, you must endure and make the show a 
success. Then you can go home and never work with that LD again. 


The Automated Lighting Programmer’s Handbook. DOI: 10.1016/B978-0-240-81553-4.00012-1 
Copyright © 2011 Elsevier Inc. All rights reserved. 123 


124 Chapter | 12 Programmer and Designer Relationships 


TYPES OF LDs 


I have found that there are four basic relationships between an LD and a pro- 
grammer. If you can learn to work with each type, then you can handle most 
any situation. Learning to read LDs to determine how they work can be difficult 
if you have never worked with them before. Of course, all these relationships 
assume that you know your console and your fixtures extremely well and are 
talented with your craft. 


1. A perfect collaboration—The LD and the programmer work together, 
bouncing ideas off each other to create the end product. The ideas for looks 
come from both, while the programmer will carry out the actual execution; 
both will take part in the creative process before, during, and after the initial 
programming. The LD usually draws the plot but looks to the programmer 
for suggestions or changes. During preproduction both the LD and the pro- 
grammer have equal input into the creative process of the show. This is the most 
common situation, as it results in the best final product for the production. 

2. The LD rules—The LD knows what he or she wants and simply tells the 
programmer what to build. The programmer is just an extension of the LD, 
executing the commands that the LD does not have the time or knowledge to 
do. The programmer does not provide much creative input and is purely there 
for data entry. During preproduction the LD will call out the looks and the 
programmer will simply input the data into the desk. The programmer might 
offer some suggestions, but the LD decides on the overall looks. In this scenario, 
the programmer oftentimes has to refrain from comment and just build the cues 
the way the LD suggests, even if the programmer has other ideas. 

3. The LD rests—The LD hands over most creative aspects to the program- 
mer. The programmer will come up with and build the looks. The LD 
may suggest a few changes when looking at the finished product, but trusts 
whatever the programmer wants to create. During preproduction, the LD 
might offer a suggestion or direction for a song or scene but leaves the 
cue creation process to the programmer. 

4. The LD and the co-LD—The programmer is actually working in conjunc- 
tion with the LD to design the show. Usually only the programmer will 
input the data to the desk, but both the LD and the co-LD consult with 
each other on every lighting decision made. Both have equal decision- 
making responsibilities and both must interact directly with the artist/client 
to ensure the overall vision of the show. This is very similar to the first 
scenario, yet a little different, as both are working as LDs. 


TROUBLED WATERS 


Some LDs might have trouble focusing on the task at hand and may be very 
busy working on other shows, conducting business on the cell phone, or meet- 
ing with the artist or client. Others will let their creative juices flow and sit with 
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you for hours painting with light, putting off everything else during the pro- 
gramming session. You must learn to cope with all different situations and 
adapt instantly. If the LD has to step away to make a phone call, you have a 
choice to make. You can sit back and wait for him or her to return, you can 
press on building looks, or you can do “desk cleanup” (labeling and 
organizing within the console). Some LDs will want to be involved with the 
look-making process (after all they are the LDs), others would rather have you 
wait, while some will appreciate your pressing on or cleaning up the console. 


CHANGING TIDES 


Of course, any given LD will behave differently with different shows. Each 
show has its own sets of constraints, and as the stress level changes, so will 
your and the LD’s personalities. For example, I once worked with an LD on 
a concert tour where we had 2 weeks of preproduction. The LD had lots of 
time to spend with me at the desk building looks. I built very few cues without 
him next to me providing input. Then I worked with the same LD on a live TV 
shoot with only 18 hours from load in to on-air. He was so busy running around 
focusing conventionals, talking with directors and choreographers, and so on 
that he had very little time to make any lighting look decisions. I had to quickly 
take charge and build the show myself. Then during a very stressed rehearsal he 
would give me notes over the headsets to finesse the cues he felt needed adjust- 
ing. I had to quickly realize the difference between the two shows and under- 
stand how our working relationship would change. Had I just sat and waited 
during the TV shoot, there would have been no lighting for the rehearsal. 


LIFE IS LIKE A BOX OF CHOCOLATES 


Life requires a certain amount of psychology, and lighting programming is no 
exception. Working many hours with no sleep and staring at a stage with lights 
flashing in your eyes can create all kinds of stress and test even the best 
of friends. There are many different circumstances and personalities in our 
industry, and I have tried to focus on the most common. We must learn to 
evaluate each situation and respond in a professional manner. Remember that 
the success of the show is the most important factor. 
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In the business of automated lighting programming, experience can make or 
break a good programmer. Throughout my years of programming I have learned 
from every designer and programmer I work with. I continue to learn with each 
new production. I asked many of my colleagues to share any advice they would 
like to pass on to others regarding programming of automated lighting. 


BUTCH ALLEN, DESIGNER AND PROGRAMMER 


Stay away from drugs. Drugs do not make anyone more creative and are just a 
waste of time, money, and brain cells. If you are going to tour, you must be will- 
ing to give up everything and live on a bus. So to prepare, you should avoid 
showering for a week, while wearing the same shirt and shorts. Behave as a pro- 
fessional, as this is a business, and save your money for when your career ends. 


JASON BADGER, PROGRAMMER 


Don’t be afraid to use something new. Always patch and palette before you get 
there (if you can). Backup every hour (at minimum) and before you do some- 
thing you’re not quite sure about. Archive all of your show files; they’I] come in 
to good use someday. Save the telephone numbers of everyone you work with. 
Don’t fear console crashes and bugs; they only make you stronger and more 
knowledgeable. Don’t try to inflict your design opinion unless it’s appropriate. 
Master more than one console. Timecode is not voodoo; don’t be afraid. 
Carry as many USB sticks as possible. Rethink what you’re doing before 
you edit 100 cues at once in a single keystroke (or at least save first). Buy 
your crew a tasty beverage every now and then. 


MIKE BALDASSARI, DESIGNER 


Without a doubt, the thing I look for the most in a programmer is their ability to 
be neat and tidy in their work. So much of designing, particularly new musicals, 
involves editing cues after you’ve been through the show a few times; therefore, 
keeping the program “clean” becomes the biggest challenge. The more time 
spent cleaning up sloppy programming once you’re in edit mode, the more 
frustrating the process becomes, the longer the process takes, and the less 
work you’re able to accomplish. Also, my favorite programmers are those 
who can program with their head up, keeping an eye on what’s happening 
onstage as we assemble cues, using muscle memory for the more mundane 
data entry tasks like selecting fixtures. ’'m always striving to work with the 
“Zen Programmers” I know who are at one with the console when we get 
into the programming groove. 

Of course, a lot of being a good programmer has to do with instincts and 
nothing to do with what button to press next. A good programmer must 
intuitively know when to make that helpful suggestion that will help to unlock 
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another burst of creativity from the designer, which is just as important as 
knowing when to sit back and just listen when the designer is in a heated 
discussion with the director or a tour manager. The reality is this is a social 
business, and the ability to get along with the wide range of people a program- 
mer has to work with is an absolute critical task that doesn’t involve any of the 
latest and greatest hardware or software. You may be the greatest programmer 
in the world, but eventually you will find yourself losing gigs to less talented 
programmers if you become known as a diva. 


RICHARD BELLIVEAU, AUTOMATED LIGHTING 
INVENTOR AND VISIONARY 


A few moments of darkness programmed into a show at just the right time can 
be more dramatic than the best lighting money can buy. 


ALLEN BRANTON, DESIGNER 


If you are busy as I have been, you try to find a programmer and work with them 
consistently. Of course, that person changes every few years for various reasons. 
From time to time I will work with someone I don’t know very well, but I really 
try to avoid that when I have limited time, a very complex show, or holes in the 
plan. What I have found is that I have a shorthand, a way of doing things that 
allows me to really be efficient at a job because % of it I don’t have to discuss 
again. As a designer you can put the lights on a plot and the programmer should 
be able to determine what you want to do with them. In the TV world you have 
very little time, so if you can really go fast and not have to discuss every little 
decision with the programmer, then much more can be accomplished. 

Recently I have been thinking about the notion of “the rules of a discipline.” 
The rules let you know what are the constraints from which you execute the theory 
and mechanics of what you have learned. It is the crux of the matter when working 
together with programmers and trying to go fast and yet not give up any quality. 
Generally, in education people come out of school or training experiences and 
they know the mechanics and theory, but they are missing these rules. I see a lot 
of people that are surprised when much of what they know runs into these pro- 
blems. When someone is really good, in the designer or programmer chair, it is 
always more effective if they have some sense of the “showcraft” that is involved. 
It is a lot of effort to squeeze your creativity into the rules of the discipline that must 
be adhered to. Unfortunately, many don’t like or don’t grasp the ability to do this. 


JOHN BRODERICK, DESIGNER 


Designers are interpreters, translating conceptual ideas into visual space. 
Knowing the language of ideas and the vocabulary of vision, just as a vocal 
interpreter is a fluent linguist, is a fundamental requirement for a designer 
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and a programmer. Lights are tools. Don’t let the tools govern you. Always 
refer back to the central concept of the project you are involved in. Study art, 
study music, study color theory. And not just the scientific theories; study the 
metaphysical and occult interpretations of vision and color. For example, why is 
there no equivalent of musical perfect pitch in the field of color vision? Why 
do two colors projected form a third color, but no two notes played together 
form a third note? Does the comprehension of light require a higher level of 
consciousness than humans have evolved to? 

Only through the study of different disciplines and the ability to fluidly 
move through them can designers and programmers release themselves from 
the harness of technology and rise to the level of art. 


DALL BROWN, DESIGNER 


Remember that lighting design is about art supported by technology. A designer 
has to have good artistic vision and well-organized technical skills. All too often 
in the rush of daily work we lose sight of the art and let the technology drive our 
decisions. Whether we are lighting an intimate scene with one candle or a multi- 
scene show with hundreds of lights, we need to be able to keep the creative 
vision alive and let it guide the design process. 

On the practical side, lighting design demands flexibility and a willingness 
to adapt. You may find yourself lighting a ballet, a museum, and a trade show 
booth all at the same time. Each one has a different team of collaborators with a 
different way of working, and all have demanding schedules. An ability to stay 
calm and organized under stress is essential, as is the ability to get along well 
with a wide variety of personality types. 


MARK BUTTS, PROGRAMMER 


Always keep this in mind: No matter how crazy things get, how tight the 
deadline or difficult the client, remember that we got into this business because 
it’s supposed to be fun. We got into this business because we didn’t want to 
work in an office and sit at a desk. We got into this business because we 
love music, theater, dance, and the arts. If you manage to make a living 
doing something you love, you are already more successful than almost 
everyone else out there slogging to work today. Yes, it’s not always perfect, 
but there are precious few people who get to turn their passion into a career. 


DAVID CHANCE, DESIGNER 


After growing up in the lighting industry, and having observed ongoing 
evolutions of equipment and control, I believe that the next decade will 
offer us a level of control and functionality not conceived by most. New 
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technologies, not yet integrated into our industry, will finally allow for real 
intelligent lighting to exist. 


CHRISTIAN CHOI, PROGRAMMER 


The three most important things you will need to keep in mind when building 
the infrastructure of your show are consistency, efficiency, and organization. 
With time and experience you'll learn what infrastructure you really need to 
start a show with, and you’ll relax about spending too much time on building 
things you might find redundant later. 


VICKIE CLAIBORNE, PROGRAMMER 


A successful programmer walks a fine line between lighting designer and but- 
ton pusher. Every designer will have their own style and personality, and not all 
will want to get input from the programmer. Get to know the LD before expres- 
sing and asserting your opinions. Then if he or she seems receptive to your 
influence, gently offer up your ideas. This will build the LD’s confidence in 
you, thereby possibly ensuring that they will call you again for their next 
show because you made them look great and you were accommodating to 
them on their terms. 


DAVID DAVIDIAN, DESIGNER 


The programmer can make or break a designer’s show. It is really important to 
find someone who has a similar, but not identical creative eye as you. They 
really need to be someone whose company you enjoy, as you will be spending 
many hours together under very stressful conditions. They need to be thorough 
and set the board up in a way that you can easily experiment on those times 
when you go dry on ideas, but also make it logical and sensible to operate 
smoothly during a show. You need their creative input always during a 
show’s programming, so I say encourage their ideas even if you may not at 
first agree. Also be sure to tell all who ask that this show belongs to the 
programmer and you both; you could not have done it without him or her. 
You also need to learn how to express your ideas in a way that the programmer 
can pick them up and express them in the console without multiple attempts. 
Nothing is more frustrating for you and the programmer than to keep explaining 
something, have it shown, and then tell the guy, no, that was not what you were 
thinking. You need to learn what you can about what the programmer needs 
from you verbally to do what you want, and you also need to be patient and 
give him or her the time to get it done. Programming is like watching paint 
dry, and patience is a virtue. Lastly, you need to keep up with what you 
have done so far, and what you need to do to know how to budget your time 
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so both you and the programmer do not have a gun to your head on those final 
few days before run-throughs. 


PATRICK DIERSON, DESIGNER AND PROGRAMMER 


About a month before I officially went freelance, I had a conversation with one 
of the most respected lighting programmers in the industry. He bestowed upon 
me some of the best advice that I was ever given in regards to this business. 
He said, “Always make sure that you’ve got some ‘F. U. Money’ so you 
don’t have to take any small gig that you get offered just to pay your rent 
that month. That way when someone tries to push you into doing a really stupid 
gig at a stupid price because they think that they can manipulate you, simply tell 
them 4 ‘F. U.’” One of my favorite quotes comes from Paul Stanley of KISS. 
He once said, “The only thing that having money allows you to do is not worry 
about money.” For someone about to start out as a freelancer, I suggest that 
you put away enough cash to support yourself without work for approximately 
3 months. If you play your cards right, then you should never have to invade all 
of those funds, but the comfort of knowing that it’s there is an added bonus 
to an otherwise scary step in your life. It will allow you to concentrate on cul- 
tivating new business instead of selling yourself scared. Always remember that 
this is a business in every way. You’ll need to budget your funds and time as 
well as market yourself as if you were a large corporation. Good luck and 
always remember to have fun! 


C. ANDREW DUNNING, DESIGNER AND PROGRAMMER 


Though knowing DMX channel counts is important when patching, don’t be 
daunted by that. A light is a light. Some simply have more attributes than 
others. One of the beauties of current console technology is the ability to con- 
figure things with that in mind. Though channel counts and attribute layout vary 
wildly, you can still easily think in terms of “Grab that light ... point it at the 
drummer ... make it red ... make the beam narrow with no gobo”—tegardless 
of who made the light or how many channels it eats up. 


MIKE FALCONER, PROGRAMMER 


Save, save, and save again. Never save over your backups, and always have 
way more backups than you could ever need. Always be paranoid about your 
show data. 

Do your homework. Know what lights you are using, how they work and 
how (and if) your console can handle them. A little homework goes a long way. 

Get proper training on your console of choice. Talk to the manufacturer or 
distributor and take the time to learn the console well. No matter how good the 
manual is, nothing beats sitting down with someone who knows the console 
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well and can answer your questions and make suggestions about what might 
work better. 

As a tule, the lighting is there to enhance what’s going on onstage. You 
should always have the best interests of the show at heart and the person 
who has employed you—light the money! 


JOHN FEATHERSTONE, DESIGNER 


There can be a temptation to use automated lights as a “decision deferment” 
tool—in other words, kind of an “I'll just throw a bunch of moving lights on 
the plot and figure it out when I get there” approach. This kind of decision 
deferment approach can leave one in the unfortunate position of trying to 
light a narrow screen surround with a wash light, or get a nice smooth backlight 
with a profile fixture, or even worse, simply not having enough lights to do 
what you really need. 

To a large extent, treat the fact that automated lights move as a bonus, not a 
“get out of jail” card. Really think about what you want the lights to do, and 
make sure you have a fixture for every task, whether it is automated or not.... 
If it is an automated light and can take care of other tasks, great. But have a 
clear understanding of what the primary, “home” task is for every light, even if 
it is just “beam effects.” If you are a designer, make sure you take the time to 
explain to your programmer exactly what every light on the rig is for. If you’re 
a programmer, ask the designer the same questions ... in short, have a plan! 


CORY FITZGERALD, PROGRAMMER 


Be ready to work ridiculous hours or not at all. Be ready to hurry up and wait. 
Be ready to eat what you can when you can. Be ready for endless days and 
weeks off; enjoy your time off when you can and don’t stop hustling for that 
next gig. Be ready to be told what to do by some people and overthink the 
problems for others. Be ready to comfort the afflicted and afflict the comforta- 
ble. Be approachable and appreciative; this isn’t rocket science and it beats 
working for a living. Be aware of the situation around, listen before you 
speak, look before you leap, and be ready to deal with whatever comes up 
without letting it faze you. Most of all, be yourself and enjoy the job; it can 
occasionally be a lot of fun. At the end of the day, remember only this: In 
the immortal words of Butch Allen, “Push button, get banana.” 


LAURA FRANK, PROGRAMMER 


Stay humble, especially when you are getting started. The desire to exaggerate 
one’s level of work experience to get those precious first jobs should not 
translate into attitude when faced with challenges on-site. After nearly 
10 years of programming, I have to occasionally pause and learn something 
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new. Those are usually the days I enjoy most. Also, before you become 
dependent on fancy effects engines, make sure you’ ve at least had the opportu- 
nity to write a 30-step offset ballyhoo on an Expression 2X. Understanding 
what the top of the line desks have evolved from is essential to being excep- 
tional in your career. 


DEMFIS FYSSICOPULOS, PROGRAMMER 


99 66, 


Do not only learn the “hows,” “whats,” and “whys” of a console, but also seek 
a good understanding and experience of the inner working of automated 
fixtures. In addition, due to the fast integration of networking, visualization 
applications, and lighting desks, a solid foundation on computers and network- 
ing I consider a true necessity. Finally, I cannot emphasize enough the impor- 
tance of education. Although this is a trade traditionally based on experience, 
technical education will teach you a way of thinking. Schooling time will 
never go underestimated in this or any profession. 


CRAIG GAFF, DESIGNER AND PROGRAMMER 


If you are programming for someone else, try to always keep in mind it is their 
show, not yours. You are just there to help. If you are the designer, the best 
thing I have ever heard came from Lawrence Upton: “Always have an idea 
of what you want to see when you walk in.” 


STEVE GARNER, PROGRAMMER 


Get as much hands-on experience as you can, whether it’s a couple of hours at 
your local rental shop or a demo room or even forsaking lunch to play with 
lights during a load in. Also, most programmers, if they are not deep in the pro- 
cess (and you will know when they are), are happy to answer questions. Make 
yourself known as someone who is interested and more experience may follow. 


JON GRIFFIN, DESIGNER AND PROGRAMMER 


I often program for a “volunteer friendly” environment. I used to do one long 
cuelist that would lead to long periods of programming time as well as not being 
functional for on the fly changes to orders. Recently, I set a new system that 
seems to fit the bill perfectly and the volunteers really like. 

We keep a notebook at FOH for every song we program to be able to repeat 
as needed by loading the appropriate list. I have also made a “busk” view on the 
console that opens up the cuelist window and splits it on each touch screen to 
allow for live busking that isn’t programmed into the show. 

Now, all of that said, the songs are built around a single main position. This 
way, when we are setup on Saturday, I update the “BAND” position and all of 
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the songs are updated appropriately. Any other positions for moves, etc. stay the 
same; it’s just their base positions that are modified. Most of the songs are built 
according to verse, chorus, verse, chorus, bridge, chorus ... depending on the 
song. In the comment field, I label it with the lyric line that it needs to run on. 

To assist with the “volunteer friendly” operation, I utilize the comment 
macro fields to set up an automated set list. This allows the volunteer to just 
keep pushing play and not worry about where things are. 


TIM GRIVAS, PROGRAMMER 


If you are a creative person, then you’re lucky. Creativity is not something you 
can learn. Download as much technical details into your brain as you can so you 
will not rely on technical expertise to make your creative ideas come true; be 
unstoppable. The automated lighting programmer of today should know 
video as well as well as lighting. 


ROB HALLIDAY, PROGRAMMER 


I think of the programmer as the pilot on an aeroplane: the person who 
ultimately takes responsibility for the safety of the flight and all the people 
on it. To achieve that, you have to have some knowledge of every part of the 
rig, both technically (the limitations of each type of moving light, the noises 
they make when they’re about to break) and artistically (why your lighting 
designer has chosen those fixtures and put them where they have within the 
context of the show). You have to take responsibility for making sure every- 
thing’s working—with careful rig checks and line up cues so you know if lights 
have been knocked out of position. And, above all, you have to know your 
‘flight deck’—the console—intimately. Ideally, well enough that you can run 
it without even thinking about it. Like a pilot, you should practice “cockpit 
drills,’ so you know how to respond quickly to the designer’s demands. 
And, like a pilot, you should make and follow your own rules about how the 
console and the showfile it contains are set out. Of course, every programmer 
might have different rules—but the important thing is to have your rules, so 
you know when something goes awry and, particularly, so you can explain 
how and why things are configured if you have to hand the show over to 
someone else. 

Then, there’s the old Vari-Lite standby: tilt first. There’s also the practical 
computer operatives advice: save often (and to many different places). And 
there’s the one I find myself saying to students a lot: use both hands! 


BRYAN HARTLEY, DESIGNER AND PROGRAMMER 


Things are totally different than they were when I started, yet they are the same. 
Find a young band or start with a lighting company. These days everyone has 
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moving lights, so your imagination is your best tool. Also, video is a great tool, 
especially when the lighting designer has control and can use it as a light as well 
as imaging. 


BUD HOROWITZ, DESIGNER AND PROGRAMMER 


Very often my programming time is extremely limited, hours instead of days. 
I frequently do not know enough about the content of the event or the music 
of the entertainer(s) performing. The first thing that I do is to spend a significant 
amount of available time building as diverse an amount of palettes as possible. 
Once the building blocks are there, creation of the “looks” is so much more 
simplified. Not having the luxury of time, much of the “process of discovery” 
must come in the building of palletized focuses. 


STEVE IRWIN, DESIGNER AND PROGRAMMER 


Programming is the technical art of converting one’s imagination into reality. 
We begin with a spark of inspiration and build that in to a mastery of light, 
color, and texture. At the heart of creation lies the ultimate in design and layout. 
We need only to allow our creative impressions to surface and unfold on the 
canvas that is our event. 

One of the biggest mistakes one encounters when programming an event or 
show is the tendency to over program. It is easy to get caught up in a whirlwind 
of creation and imagination. Focus and clarity are what are needed at this 
moment. It is also important to build your looks with the event in mind and 
not just what one thinks looks cool. 

When programming, take into account all of the ingredients that brought 
you to the show. This will allow you to remember not only why you came, 
but also why others came who are attending the event. With that knowledge 
you can create programming that is appropriate to the situation, and your light- 
ing cues will have the proper impact intended by those who hired you. 


SETH JACKSON, DESIGNER AND PROGRAMMER 


The development of automated lighting, the consoles, and indeed the program- 
mers themselves has evolved from a handful of people at two or three companies 
in the 1980s to a fully developed industry today. Words like “effect engine,” 
“bally,” “pan chase,” and “position presets” are new to the larger vernacular of 
lighting design. Those of us that were around during the “early days” of this 
business learned some key principles that must not be forgotten. In short, neat- 
ness counts. The difference between someone who runs a console and someone 
who is a skilled (better known as employed) programmer relies completely on 
those two simple words. If you are messy with your programming, the console 
can bog down and not perform at optimum efficiency. If you can’t track your 
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notes and changes effectively, you will look quite stupid when the designer starts 
asking questions. If you let things get into cues that aren’t built around presets, 
you will find yourself hunting for hours. Finally, if you aren’t organized in your 
file structure, your saving habits, and your console layout you might find yourself 
spending countless hours doing things twice, or worse, out of a job. In short, be 
unapologetically, unabashedly...anal. 


MARK “JUNIOR” JACOBSON, DESIGNER AND PROGRAMMER 


Do everything you can to resist using “hard values” in cues. Presets are your 
friends. Positional focuses are the ones that most people remember to stay on 
top of, but everything from colors to shutter speeds can be just as important. 
Anything that’s not working in the show is much easier to fix once than it is to 
try and track it down in every cue. Labeling should be clear enough to be obvious 
not only to yourself, but also to anyone else who might be accessing the console. 
Cryptic consoles aren’t the best form of job security; your skills and personality 
should accomplish that. Setting up a good screen layout is vital in being able to 
act quickly and efficiently. You don’t want to pause and think about where your 
position palette is, for example. It should become second nature. 

Seek as much knowledge as you can. If you are serious about being as good 
as you can, you should be willing to put in your own time to get there. You 
can’t expect to excel if you are only willing to spend someone else’s time or 
money to achieve it. 


SHANNON JANUARY, DESIGNER AND PROGRAMMER 


There’s no such thing as an intelligent light; there’s only stupid equipment 
and intelligent programming. Don’t be afraid to do less. Just because a fixture 
has dozens of attributes and features doesn’t mean you have to use them. 
Doing too much in a cue tends to diffuse the impact of a moment. On the 
button of a number, do all of your fixtures need to bump color and sweep 
to center? Will just a color bump do, or just the sweep? If the moment 
needs both a sweep and a bump, sweep one group or type of fixture, and 
color bump another. 

Painting cool pictures on stage is the easy part. If you can turn the board 
on and grab a fixture, odds are you can create a good look. The challenge of 
good programming is transitioning from one great look to another and having 
it look good in between. Do that and you’ll spend more nights in hotel beds than 
your own. 


DAVID “GURN” KANISKI, DESIGNER AND PROGRAMMER 


Every gig is different and has its own set of challenges. Come into every project 
wide-eyed and ready to face it in a new light. Of course, apply your experiences 
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and knowledge, but never be so set in your ways that you block out new ideas 
and concepts. Most of all, don’t be one of those programmers who is 
unapproachable. 


MATS KARLSON, PROGRAMMER 


Before programming anything, make sure you know your fixtures. Understand 
what they can and cannot do. Every fixture has its strengths and shortcomings, 
and much valuable time can be wasted trying to program something that the 
fixture can’t perform. Reading the fixture manual and spec sheet helps, but 
spending a little playing around with the fixtures is even better. 


ERIC KENNEDY, PROGRAMMER 


Always try to strive to do well at what you do, to recognize your strengths and 
weaknesses, and try to always keep seeking inspiration and excellence. Always 
take the time to look at and analyze the light plots you work on, to look at 
an LD’s work, and try to understand both the equipment and how he or she 
used it. Everything you see and learn will help you to form your own style, 
and don’t be afraid to copy what you like—you certainly won’t be the first, 
and that is the first step toward finding your own voice. And just as you can 
learn from others, you need to look at your own work and think what could 
be better. 


TOM KENNY, DESIGNER 


Patience is the best virtue to have in a programmer or while programming 
lighting. When you are under pressure, the best comes out in you. The more 
you practice, the better you treat situations, and the better your work becomes. 
Just remember that first you have to learn the basics of lighting! 


HILLARY KNOX, PROGRAMMER 


Lots of designers depend on programmers for creative input. When this is 
required, do something original; create something that everyone hasn’t seen 
before. Now, this doesn’t have to be a groundbreaking never-before-seen 
idea in lighting design; it can be a simple twist on something that you know 
that will work, but take every opportunity to try something new. 

Time is always a factor in lighting. Ninety-seven times out of a hundred, 
you'll be under some sort of pressure to work quickly. Ten times out of 
a hundred, you’ll be under intense, submarine captain torpedo-in-the-water 
pressure. It’s one of the harshest realities that you just have to learn to deal 
with. If this is the kind of thing that you just can’t deal with, then maybe pro- 
gramming (as a career) isn’t going to be your thing. Not to sound discouraging, 
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but if your job is going to make you intensely stressed out on a regular basis, 
you have to ask yourself if it’s really worth it. 

Unfortunately, time management is one of those skills that can’t really be 
taught, but fortunately, for most people it improves with experience. If 
you’re in the heat of battle and have no time to think about anything except 
the mechanics of programming, I find that it’s probably best to let the 
designer manage your time for you. At that moment, your job is to complete 
the current task, while the designer, who has the ultimate responsibility for 
the completion of the design, has to keep the big picture in mind at all 
times. Because the designer has this responsibility, he or she can (should) 
keep an eye on the clock and make presumably intelligent decisions about 
how much time should be spent on a particular cue before moving on to 
the next. 


MARCUS KROMER, PROGRAMMER 


Never stop learning. Things in our world develop with high speed. You are in 
charge of knowing the software and the equipment that you use, consoles and 
whatever you control with them. Try out things before you really need them; 
downloading a manual when the designer is already waiting is not the best 
option. Out of all the options that a console has, you have to choose the one 
that fits to the challenge that is given to you by the designer. Use your time 
with the console (or the pc editor). Think about how you organize your console 
and data. Make sure that every single preset, cue, chaser, etc. is labeled 
correctly, so you can recall it quickly. Don’t overcomplicate things just because 
you can. Very often you need to be able to choose the right version of software 
in advance. The latest release is not always the most reliable one. Also keep an 
eye on the latest moving light or media server. Make sure you have the correct 
fixture libraries when you are starting a show. If you are prepared and the setup 
is well done, you will have an easy job; if the setup is not correct, it will for sure 
complicate things afterwards. 


JIM LENAHAN, DESIGNER 


The most important time a touring lighting designer will spend is in program- 
ming before the start of the tour. Ninety percent of the looks on the last show of 
the tour will be ones that were developed during that time. But it is also the 
hardest time to convince managers to pay for. The reason is simple. Money 
is going out for lighting equipment, crew, and stage rental and nothing is 
coming in. A friend of mine who is a film director of photography once told 
me something, which I think also applies to live touring. He said, “How 
good a show looks depends on how well it is lit. How well it is lit depends 
on how much time is spent on lighting, and time costs money. That is why 
making shows look good is expensive.” This certainly applies to programming, 
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and it is the hardest thing to make managers understand. But every extra 
programming day you can pry out of them will be worth its weight in gold. 


STEVE LIEBERMAN, DESIGNER AND PROGRAMMER 


Programming moving lights can be a somewhat daunting and often challenging 
task. That being said, it is important to start your programming session with an 
understanding of what you aim to accomplish. You should always have your 
laptop with you! Keep copies of the latest software for your console as well as 
previous versions. It is also important to save your show to your hard drive, 
not just floppy disks. This is probably the most important part of programming! 

There are several ways to achieve the same results. My best advice would 
be to learn the long way first so that you have an understanding of the syntax. 
Do not be afraid of your console. As long as you save often, you should be 
willing to hit every button. If you don’t know what a button does, ask. If 
you encounter a bug in the software, report it. This helps all of us. When 
there is an opportunity to sit next to another programmer while they’re 
working, do it. You’ll probably learn something you didn’t know before. 
Always be willing to help others. 


ESTEBAN LIMA, DESIGNER 


Don’t be afraid. The technology can be daunting, but it’s really there to help you. 
No one is going to think ill of you if you ask for help or advice, because that’s the 
way most of us have learned. Take the work opportunities as they come. The worst 
that could happen is that you’ ll learn something new, and if you don’t get that same 
gig again, you’ll use your new knowledge in the next one. Be nice, be very nice, 
especially among your peers; remember, a lot of the work you will get will come to 
you through recommendations, which are based, among other things, on your 
reputation. Nobody wants to work with people who can’t get along. 

Use all the resources available to you, read the manuals, read this book, and 
keep it close to you. Make yourself a student all the time; do research when you 
have free time at home. Keeping your knowledge up-to-date will give you an 
edge—you will be surprised at how many variables there are in our industry 
that affect the technology we use. 


HEATH MARRINAN, DESIGNER AND PROGRAMMER 


Don’t fall into bad habits because of laziness. What I mean is, if you are wasting 
time while you’re programming and you know what the solution is to make 
your programming more efficient, then stop and take the time to fix it. When 
an LD is shouting out programming instructions, it is a programmer’s job to 
make those tasks happen in a timely manner. That is why I stress just before 
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we set the board up before our tour or show. To make tasking faster, we can 
always make small changes that save huge amounts of time. 

Also try and challenge yourself instead of doing things you already know 
how to do. You won’t learn if you don’t try and make your time with the con- 
sole as valuable as you can. So make sure you throw some tough tasks in there 
so you are better rounded with the console. 


MICHAEL NEVITT, PROGRAMMER 


LDs request the same programmers over and over, mainly because of three 
factors: personality, speed, and creativity. It is hard to teach how to be person- 
able, low stress, etc.; you have it or not. Programming speed can be learned if 
you have the ability. Creativity is a natural part of some. If you have the ability, 
it can be refined. Learn the art of lighting first. Build a strong background in art, 
architecture, music, theatre, dance, photography, etc. A great programmer 
has the not-so-common ability to balance between the artistic and technical. 
Maintain that balance. 


ADRIAN NGIENG, PROGRAMMER 


Be humble. Learning from the great ones in your life will not stop. Learn new 
things. Automated lighting is not just swinging the lights but being creative and 
making full usage of the functions and creating the most beautiful scene you can 
imagine. As for a programmer, the most important things that you have to know 
are that your console is 100% operational and the functions of the fixtures that 
you are programming. With those skills, nothing will stop you from creating 
scenes that you can imagine. Last, but not least, PRACTICE MAKES 
PERFECT! 


PAUL NORMANDALE, DESIGNER 


The darkness comes free—use it. 


JIM OHRBERG, DESIGNER AND PROGRAMMER 


A programmer should give proper attention to the initial setup and configuration 
of a new show; it is the effort that goes into this preparation that can have the 
greatest impact on speed, clarity, and efficiency of programming throughout 
the production process. Foremost is the organization of the programming data: 
channels, instrument numbers, groups, cues, cuelists, stacks, chases, macros, 
and other console information. Take the time and plan a logical method of layout 
for all of these elements. There are many available methods for using numbers 
and text labels to create systems of data organization within the console. Review 
different organization methods, pick one that makes sense to you, and follow the 
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method consistently. Proper organization requires an initial time investment, but 
it rewards you by allowing faster programming and greater readability of your 
show file. Readability and organization are both important when you, or another 
programmer, need to make adjustments to the show at a later date. 

While planning console data organization, also consider the multiple types 
of users that will need to use your show file long after the programming 
sessions: designers, playback operators, maintenance technicians, event staff, 
and other programmers. Create screens, cuelists, macros, or external interfacing 
to allow each of these users to achieve their goals without having to fully under- 
stand the console or the contents of the show file. Making console interaction 
easy for all users will go a long way in enhancing a programmer’s reputation 
and will make them a more desirable team member for future projects. 


STEVE OWENS, DESIGNER 


When you start your programming, you may or may not have a concept of what it 
is that you want to see. There is a formula that I follow. A start point (setting up of 
your console)—this is what I find to be the hardest part: setting up your groups, 
colors, beams, and preset focuses. I’1l do a basic block format on the board. Then 
as Iam programming each song I will add to my palettes, such as new focus posi- 
tions and new colors, etc. I try not to be repetitive, meaning not to see the same 
things over and over. Start off with a WOW. Then settle in to a groove for a while 
and start building and building. So then you’re heightening their senses without 
anyone knowing it. Then throw in the hammer, kill ‘em. Throw the whole nine 
yards at them. Something to leave them in awe and still wanting more. 


MITCH PEEBLES, PROGRAMMER 


I like to hold back on effects like strobing and even movement. Just because a 
fixture has pan and tilt capabilities doesn’t mean the fixtures need to be moving 
all the time. Sometimes the best lighting is lighting you don’t notice. 


PAUL PELLETIER, PROGRAMMER 


The planning is very important; get all the information you can weeks before 
you start the actual programming: fixture type, controller type, user manual 
for all the equipment used. Specify in advance all the settings for the fixtures 
like DMX address, mode, and special fixture personality settings. 


JOHN RAYMENT, DESIGNER 


What folks who watch shows remember about the lighting is the 
pictures we create. Not the hardware but the light. Lighting is a performed 
design—and many designs today rather demand a computer (or two or 
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nine) to run the “performance.” Enter the programmer: the designer’s 
vital associate. There is an unspoken contract between the designer and 
the programmer(s)—we need each other (and the lighting design needs 
both of us). 

What do I seek from a programmer? Above all, a genuine interest in the 
lighting—there is a distinct difference in working to achieve a design rather 
than playing with a console; and then the basic stuff like real competency in 
the console. It is your job to know your equipment—and the smarts to know 
what you don’t know; and, please, the human comes before the machine. 
The effects generator is a tool, not a creator. 

Lighting designs have personality and the rapport between designer and pro- 
grammer will have a substantial bearing on the final result. If we are enjoying 
the mutual challenge and context of the pictures we are creating, then the 
chances of a happy result are greatly increased. And the final 10% is always 
the hardest to achieve. 


BENOIT RICHARD, DESIGNER AND PROGRAMMER 


The key to a successful production is simple: You have to know and under- 
stand the main subject of what you are going to light; especially for the 
concert industry, where you should listen to the songs over and over before 
you can even start to program the cues. Months before I program a tour, 
I listen to the songs in my car so many times that all the intros, accents, 
and endings are subconsciously printed in my mind. Once I know what’s 
going on in each song, I'll sit down and “chart” each moment (cue) and 
basically create the first draft of my show cuelist. With an offline editor, 
I immediately enter those blank cues in the main list. Then, when I arrive 
at production rehearsals, my extensive knowledge of the material will flow 
naturally from my thoughts, through the console, and make sense of each 
part of the song I am trying to light. 


SCOTT RILEY, DESIGNER AND PROGRAMMER 


When going into production, there are many things that you can have prepared 
as a programmer to make your sessions as time efficient as possible. Starting off 
with an organized approach to your palettes, groups, and even user numbers can 
have a substantial impact on what you are able to achieve with the limited time 
that is usually available to program a show. It is fairly common to keep a library 
of all the palettes that one creates per fixture type for the control desks regularly 
used. This way, setup of the desk for each show can be expedited by utilizing 
the palettes created for previous projects. The key here is to organize them in a 
fashion that allows you to have all the tools available to you without taking up 
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too much real estate. Combining like colors together into palettes for multiple 
types of fixtures as well as placing similar functions together such as strobing or 
gobo rotations can allow for more dynamic control while preserving space at 
the same time. 


LARRY “UNCLE FESTER” ROBBINS, DESIGNER AND 
PROGRAMMER 


Anyone can learn a board; no one can teach that person how to program and be 
creative. Too many people think just because they learn a console, that makes 
them a programmer. They miss the most important aspects: 


1. Knowing the lights, their functions, and how/what to light; 

2. Knowing a good variety of boards and controllers; and 

3. Most important, being able to cope with the pressures of no time, crazy 
producers, clients, or lighting directors. 


TIMOTHY F. ROGERS, PROGRAMMER 
The three most important qualities that a good programmer needs to have are: 


1. The ability to communicate well with others. Communication is one of the 
most important jobs of a good programmer. 

2. Having a great eye. For example, the ability to blend the automated system 
with the conventional system, to know what color or image fits the mood 
or feeling on stage. To be a good second set of eyes for the designer is 
wonderful help during the design process of a show. 

3. Speed. Speed is of the essence while programming a show. The last thing 
that the designer wants is to have to wait for his or her programmer to 
complete a task. If the task at hand is going to take some time, just explain 
that to the designer or the director (communication) and if time allows, 
complete the task. Knowing your desk and being able to think about what 
you have done and what you are about to do as well as what might be 
coming up are all important elements to speed. 


SUSAN ROSE, PROGRAMMER 


Try to work with every type of moving light that you have the opportunity to do 
so. Don’t be afraid to experiment with all of the parameters. You can come up 
with some really cool stuff by accident sometimes. But if you really know what 
the particular moving light is capable of, you can come up with specific looks 
much more easily. Always keep learning new consoles, and always keep 
learning more about the consoles that you regularly program on. 
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ARNOLD SERAME, DESIGNER AND PROGRAMMER 


If you don’t like being away from home and working long evening hours under 
adverse conditions and sometimes intense pressure, then GET OUT NOW! And 
don’t listen to negative people. Just because you can do it all doesn’t mean you 
can. Listen to what the material is telling you to do. Don’t create lightshows. 
Create lighting for the show. Keystrokes are only the beginning and the least 
important part of what you have to learn. Study music to learn structure and 
how to anticipate what a musician will do onstage. Study writing for structure 
and storytelling. Study architecture for shape, space, and form. Study painting 
for color, light, and shadow. Study the kinds of things the people you want to 
work with study so that you can talk to them as an equal. Study what you’re 
passionate about and make it a part of what you create. Remember joy. People 
like working with people who really enjoy what they do. Make it easy for 
people to work with you. Make it easy for people to call you for that next 
job. Concentrate on the gig you’re on. Throughout your career, have faith in 
the following maxim: There aren’t enough good people to do what needs 
to be done. Somewhere out there, some artist, director, manager, lighting 
company, and/or production manager is looking for the next hot lighting 
person, which naturally leads to the next directive: Make it easy for people 
to find you. And this above all: Throughout your career, keep on refinding 
that sense of magic and wonder that brought you to lighting in the first place. 


MARSHA STERN, DESIGNER 


The first thing I like to do when beginning a program for automated lights is to 
visualize the entire sequence of events. Sometimes I just close my eyes and 
visualize the way I want everything to look. Then I break down the look into 
its respective segments, the building blocks so to speak. I like to think of the 
lighting cues as bits of animation. It may take many cues to create the overall 
look or desired effect just as it takes many drawings to create movement from 
the animated character. 

It is not always necessary to move/flash the lights to create an exciting 
visual effect. The “less is more” policy is one that I subscribe to. Truly, we 
can best notice the movement when it is next to stillness, just as we take notice 
of the color and light more when it is next to darkness. I think that contrast is an 
important concept in dynamic programming. 


HENRY M. SUME, DESIGNER AND PROGRAMMER 


I am constantly surprised and fascinated by the evolving nature of being a 
programmer. Today’s programmer is much more of an integral part of the 
lighting team than even just a few years ago. Where shows used to be mostly 
conventional with maybe a handful of automation thrown in for “flash and 
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trash,” now the opposite is true. The automated fixtures are carrying more and 
more of the workload of creating and sustaining the visual feel of the show. 

As a programmer, you’ll often find yourself acting as one big interface. It’s 
your job to translate a designer’s language into a language that the console 
understands. Further, you have to translate between the way the console oper- 
ates and the way your specific fixtures operate. That’s not to say that the role of 
programmer is artless. Far from it—oftentimes as a programmer you have a 
much more direct influence on the visual impact of the show than just about 
anyone else involved. That said, while you’re working on a show, the greatest 
skill you can have is knowing when to discuss things and give your opinions 
and when to just shut up and punch the buttons. Whenever possible, STAY 
BEHIND THE CONSOLE! A programmer is no good to anybody if no one 
can find you when they need you. 


HOWARD UNGERLEIDER, DESIGNER 


A really amazing programmer is a very in-tune person, with ability to understand 
not only exactly what a designer requires, but also the operation of whatever con- 
sole the designer chooses. The programmer must implement the designer’s 
requests with lightning speed as well as accuracy. Knowing the console’s short- 
cuts and syntax are imperative. They also must have a pleasant demeanor so that 
they blend in with the designer’s vision and never walk over or around the 
designer’s creative process. Being intimate with the lighting plot and understand- 
ing each and every fixture along with their personality will help the programmer 
deliver the end result that the designer requests. These important steps will ensure 
that you will be called on frequently due to your excellent working standards, and 
also word of mouth referring to your work ethics. 


LAWRENCE UPTON, DESIGNER 


It is important to establish a relationship with your programmer and his or her 
requirements. Do as much homework as possible on your knowledge of the 
instruments. Above all, be patient. Work to establish your overall aims and 
then work from there. Understand that too much information at one time may 
slow the process down. The prohibitive cost of having a lighting system 
available to you in a facility is the most valuable time you will have. It is 
important to work on a time schedule that will give you enough time to 
cover all the elements you need to light. 


JON “HILLBILLY” WEIR, DESIGNER AND PROGRAMMER 


It’s often the simplest things that have the biggest impact on how we work as 
programmers. Desk layout, cue structure, and knowing your console are 
imperative. Know the fixtures you are using. There is no perfect automated 
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fixture or media server. All of them have strengths and weaknesses. Know what 
the strengths are and use them to your advantage. Learn the weaknesses, and 
then learn how to work around those weaknesses. Different fixtures have differ- 
ent features. Sure, some of the basics are the same, but deeper down there are a 
lot of differences. For example, color mixing. Tons of fixtures on the market 
offer color mixing, but systems differ from manufacturer to manufacturer. I 
know that on X fixture, [’ll have trouble being consistent among fixtures in 
the green range, and it’s going to take extra time to match them all. On Y fix- 
ture, it’s going to be very quick on snaps. Z fixture may have a beautiful range 
of colors, but be slow on color changes. Learn these little idiosyncrasies and use 
them to your advantage. Intimately knowing the fixtures you are using will help 
you get the most out of them. 

I ALWAYS keep a notebook right beside my console. Write down any notes 
you have. During rehearsals it’s not uncommon to be calling spots, with a direc- 
tor in one ear and a stage manager in the other ear all calling cues or asking for 
something at the same time. It’s a hectic environment at best. Artists will always 
change what they are doing on stage. It’s our job to make them look good no 
matter what they do. So, if I notice that band has added an extra chorus to a 
song, or changed how it ends, I'll make a note of it so I can fix those cues the 
next day. When I’m on tour, each city gets its own page in the notebook. That 
page is dedicated to programming, song, fixture, and general show notes. 


ROSS WILLIAMS, DESIGNER AND PROGRAMMER 


A common misconception appears to be that the job of an automated lighting 
programmer is simply that of a computer terminal operative. In reality, the 
demands are far more wide-reaching, encompassing both technical and creative 
practices. 

This commonly extends the remit beyond the common role of assistant 
lighting designer, to digital content creator and beyond. The entire visual appear- 
ance of a production can become the responsibility of the automated lighting 
programmer all too quickly, adding considerably to the levels of responsibility. 

On the positive side, there is plenty of scope to exercise and develop varied 
levels of interest and skills across these workflows, and there is now something 
for everyone more than ever before. 
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FIGURE A.1__A bold lighting look during the Sydney 2000 Olympic Games Opening Ceremony. 


The 2000 Summer Olympics held in Sydney, Australia was a magnificent time 
for many of the greatest athletes of the world to gather and compete. As with 
most modern Olympic games, extravagant productions marked the opening 
and closing of the games. Because the show took place in a giant sporting 
arena and would be seen by more than 4 billion people live via television, 
every bit of the production was large-scale. In fact, even the venue was built 
to serve two main purposes: the athletic events and the opening and closing cer- 
emonies. I was honored to be part of the lighting team for these worldwide 
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TABLE A.1 The Automated Lighting Programming Team 


John Rayment Lighting Designer 


Rohan Thorton Lighting Director 


Trudy Daegleish Associate Lighting Designer 


Jo Elliot Assistant Lighting Designer 


Dave Wilkinson Jo’s Assistant 


Robert Bell Wholehog II pogrammer and On field Cyberlights 


WYSIWYG Specialist 


lan “Gooche” Blackburn — Wholehog II programmer One quarter of the main 
field fixtures (Closing 


Ceremony) 


Vickie Claiborne Wholehog II programmer One quarter of the main 
field fixtures and 


conventionals 


Jason Fripp 


Mark Hammer 


Rohan Harrison 


Megan McGahan 


Jason McKinnon 


Wholehog II programmer 


Wholehog II programmer 


Wholehog II programmer 


Strand 550i Programmer 


Wholehog II programmer 


One quarter of the main 
field fixtures 


Stage fixtures 


One quarter of the main 
field fixtures 


Audience lighting 


Rooftop Space Cannons 


Dean Price Wholehog II programmer/ Field Space Cannons 
Space Cannon Technician 
Brad Schiller Wholehog II programmer One quarter of the main 


field fixtures and 
conventionals 


Brendon West Wholehog II programmer Field Space Cannons 


spectacles. There were far too many people involved in the production for me to 
list them all here; however, Table A.1 lists those directly involved in the pro- 
gramming of the automated lighting. 

The tremendous effort put forth to make these productions successful can 
only be credited to everyone on the team. I think this show was one of the lar- 
gest collaborative efforts of lighting programmers to date. I felt it would be ben- 
eficial to myself and our industry to notate our experiences as they happened. 

What follows is my daily journal that I diligently kept while working on the 
shows. Usually returning to my temporary home early in the morning after 


Appendix | A Sydney 2000 Olympic Games Journal 151 


FIGURE A.2_ Brad Schiller at his console prior to the Sydney 2000 Olympic Games Closing 
Ceremonies. 


programming all night long, I would spend 10-15 minutes writing out the 
events of the day. 


BRAD SCHILLER’S OLYMPIC JOURNAL 
Day 1, August 21, 2000 


Today was the first day. We started out at Spectak Productions. In a small room 
we had 7 Wholehog IIs and 7 WYSIWYG computers, each with a vision 2000 
(see Figure A.3). Each of these computers was hooked up on a network as well. 
There are 21 monitors to support all this gear. We spent part of the morning 
hooking up monitors and getting things in place. We then talked with John 
Rayment (LD) about some of his plans and goals for the show. 

I cleared all the desks, added the current software and merged in the patch from 
previous test disks. We all then set to the task of building groups as defined by John. 
Once the groups were built, then we had to discuss how he plans to call the fixtures. 
There are numbers everyplace (DMX, tech numbers, LD numbers, console num- 
bers). We decided to number things the way the LD was used to them and we 
had to rename our groups to match this. Jo (assistant LD) kept bringing us paper- 
work with various numbers and charts and we kept updating and building groups, 
all the while making sure we were each building the same things. We also built 
seven simple color palettes to match the colors in the scrollers. (Figure A.3) 
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FIGURE A.3 Consoles and WYSIWYG computers setup at Spectak Productions. 


While the four main consoles were busy with this, Dean was busy building 
his own groups, palettes and effects with the Space Cannons. Robert Bell was 
continually updating the WYSIWYG file via the network. His console will control 
the 20 Cyberlight fixtures on the set pieces, so he was concentrating on the 
WYSIWYG and not worrying about his Hog show. Mark’s desk has Studio Colors 
and conventionals on it (set lighting) and he spent the day building his groups and 
palettes (and updating and correcting the WYSIWYG file with Robert). 

After lunch we started the task of positions. Everything in the show is based 
on a huge grid laid out over the field. The grid is 29 x 47 squares. We have to 
make position palettes for about 1/3 of these. The plan is to use Auto Focus in 
WYSIWYG, but there is a hardware problem with the MIDI cards, so this 
is delayed until tomorrow. In the mean time, we had to discuss the best way to 
organize all these positions so when the LD calls out position F-20 we can quickly 
find it. Since we did not have the auto focus working, we started out making the 
palettes by hand. This gave us plenty of time to figure out the best way to organize 
the palettes. We decided to use the page up and down keys to make a page for each 
letter of the alphabet (plus the three double letters) and have all the positive and 
negative number positions for that letter on each page. We are even going to try 
to make macros to jump directly to each letter so that we can speed up the palette 
selection process. It would make sense to just give each position a unique 
number and key them in, but since the entire production from sets to choreography 
to lighting use the same grid system we have to maintain consistency. 

At the end of the day we all had completed one line (the center “O” line) con- 
sisting of 23 palettes. Robert Bell was going to stay late to try to fix the WYSIWYG 
problem. For disk saving we decided to run on a three disk leapfrog method. At the 
end of each day I archived each final day show disk to my laptop. We also switched 
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to new disks at least once a week to ensure good disks. Tomorrow we are planning 
to start by viewing the video of rehearsals and then finishing the positions. Once 
those are done we will start on the cuing (which John calls “plotting”’). 


Day 2, August 22, 2000 


Today we started by viewing the videos of the opening and closing ceremonies. 
These were videos that were made by the Olympic committee to present the 
concepts of the shows. All I can say is WOW! This is going to be a huge spec- 
tacular. There are some amazing things that are going to happen. 

Today we started by updating the 145 positions we each have. We used the 
Auto Focus feature of WYSIWYG, which made a huge difference. We would 
click on each point in the grid and then just record the position. This was so 
much easier than moving each fixture one at a time. Of course, when we get to 
the arena we will have to update each and every fixture in each and every position. 
We decided to use the “page down” method for each letter of the alphabet and this 
seems to work well. I built 30 macros to assist in jumping to each letter. We then 
merged these macros into each of the other three consoles. After this was 
completed, we all built stage focus positions. This was challenging, as we had 
to adjust the height for each of the four stages in WYSIWYG as we went along. 

Next John Rayment came in and described some looks he wanted. We had 
to build the fence wash. This is a straight down focus around the edge of the 
track. Next we had to do a “horse wash,” which is a crossed focus on the 
fence line. This sounds simple, but for the west side we have two programmers 
that have to coordinate their cross focus so that the end result is a symmetrical 
focus. Next the east side desks have to make their focus match the west side. 
The problem becomes deciding the best way to do the cross focus. At first 
all four of us set out with our own processes for the focus. We quickly 
found out that we each were using a different method. We had to stop and deter- 
mine the best way to do this and then all build the focus. Using the WYSIWYG 
we each turned on a view to enable us to see our east or west partner. 

Vickie and I brainstormed about the closing ceremony. There is no rehearsal 
for the show. We will have to “wing it” for most of the show. We are planning 
to propose to John to build 30 or so “on the fly” looks and chases that are the 
same on each desk. This way he can call for the random color chase on the main 
stage and then all of us will have the same effect. We will see what he thinks. 
Tomorrow we are going to the stadium to test our shows and see that everything 
is working correctly. Then the next 5 days or so we will be building the cues. 


Day 3, August 23, 2000 


We started out the day back at the Spectak office where we first watched some 
videos of the rehearsals and an animation of the horses. After that we began to 
build what are called “patterns.” These are focus positions that form a certain 
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pattern. We first defined four sections to start with—all in the form of the 
Olympic Rings. We now have the “Arrivals” rings and the “Arrivals” pools. 
We also have the “Horses” rings and the “Horses” pools. We were very careful 
along the way to decide on the name of each position and make sure we all refer 
to it with the same label. Next we had to figure out how to build what the LD is 
looking for. This was straightforward for the pools, but the rings proved to be a 
challenge. How do you split 4 desks across 5 rings knowing that later you do 
not know which lights will be used for which portion of which ring? We all 
brainstormed on this trying to decide the best approach. We finally decided 
to try an idea from Jason. We each divided our lights into groups of ten and 
built each ring 6 (or 7 depending on the desk) times. This way we can use 
some or all of our lights to form any part of any ring. We then each set out 
to build all these positions. With 70 fixtures and 10 positions on each ring 
this took some time. Jason and Rohan used the WYSIWYG method. That is, 
they used Auto Focus to click on their screen each position and then record 
this to the desk. Vickie and I decided to do it the old fashioned console method 
and just dialed all our lights into position. When we completed these tasks, then 
we all packed up and went to the stadium. 

We arrived at the stadium and went to see our home...WOW, we will be 
sitting just below the mega-VIP seating (royalty, presidents, and the like) and 
are in the prime spot in the very center. We then loaded up our shows and 
started to play with the lights. As we predicted, the positions were close 
but not exact due to differences in fixtures versus WYSIWYG. We all then 
started playing when we noticed a problem. We have a steppy DMX problem. 
When the lights are moving slowly then they appear steppy. We do not know 
if the problem is a Hog problem or a problem with the Strand Ethernet 
network. The crew is going to test this by running a line directly to a console 
and see what happens. The problem is not seen in the WYSIWYG (even on 
the network) so we suspect the problem is in the boxes that convert the 
Ethernet back to DMX. After that we all went to a pub right next to the 
stadium and had some good beer. 


Day 4, August 24, 2000 


We started the day by building the focuses for the “Horse” rings. John had pre- 
charted which fixtures went to which rings by groups of ten. We then set out to 
combine our groups to make the circle. Usually it was three programmers to 
make the ring. It took a few minutes, but Rohan soon figured out a good 
method. He suggested that we each divide our ten lights and place the farthest 
two on a tangent to the circle and then fill in the gap evenly. This worked well 
and in no time we had five perfect ring focuses built by combining four desks! 

Next it was time to start plotting (cuing). John came in and we all built 
cue |. It was a big moment! As we continued building the cues we would all 
talk about how to build the needed effect and then each build it in the same 
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manner. We also moved very carefully to make sure everyone was on the same 
cue. Mark was not there today (and will not be for several days); also Dean was 
not there. Robert took over on Dean’s console and I programmed Mark’s and 
mine. It was a little confusing at first until I got around his groups and built 
some of my own. Eventually Robert had to stay at Dean’s desk so for a 
while I was programming cues on three desks at one time! Sometimes, Vickie 
would lean over to my desk and build the cue if I was busy on the others. It will 
probably stay this way for the next few days. 

This morning while building some of the first cues, the solution to the 
steppy Cybers we saw at the stadium the night before came to me. I remem- 
bered that the fixture library we are using has a bug with the Mspeed channel. 
The default was set for the fastest Mspeed and not Xfade. This is why we saw 
the jittery beams. I then realized it all clicked and all the symptoms pointed to 
this as the cause. The fix is very simple (change the default). I told John what I 
thought of and he immediately called the crew at the stadium. They agreed 
that this looked like this could be the solution. Tonight they tried it and I 
was correct...the problem is solved! Next we found a problem with the Mspeed 
chart for Cyberlight. I have confirmed (using Status Cue software) that the 
Mspeed chart used for Cybers is NOT the same as other High End Systems 
(HES) fixtures. When I finish writing this, Vickie and I will build the new 
chart into the Hog library. Vickie will bring up the values in Status Cue, 
view them as both label and DMX, then tell me and I will enter them into 
the library. In the morning I will rebuild all the shows with the new correct 
Mspeed library. Wow, we have had fun with Mspeed. 


Day 5, August 25, 2000 


Today I started by trying to load my new library for the Cybers. For some 
reason there was a bug that was ignoring the invert for the color channels. 
This was really annoying me, as I did not even change the color mix 
channels, but the Hog was inverting them. It took an hour off the morning, 
but I finally figured out how to fix this. Once I managed to merge in the cor- 
rect library I realized that this would cause all the position focuses to scrunch 
up one after the other. This would destroy the nice charting we made of the 
145 positions. So we skipped all this and started plotting (cuing). We built a 
really cool chase that was building the 5 Olympic rings as the horses ran 
through them. This required a coordinated effort of 30 cues between the 
4 desks. This took some time, but we got it worked out so that we can 
make the cue work. After lunch I was charting Mspeed trying to make 
a conversion from the incorrect chart to the correct chart to avoid the 
merging. Vickie suggested making palettes of the common Mspeed values. 
We built the palettes based on what the Mspeed should be and assigning it 
to the equivalent incorrect Mspeed chart in the library we are using. We con- 
tinued building cues and I was still programming on two desks. At the end of 
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the day we had all built about 100 total cues and made it about 2/5ths through 
the show. Tomorrow is a day off and Vickie and I plan to go with Henry and 
Victory to experience the Sydney Harbor Bridge climb. For a small fee we 
will get to climb to the top of one of the most famous bridges in the world 
and enjoy a splendid view of Sydney Harbor. John is going to a rehearsal. 
After this we will not get a day off again for 3 weeks until after the show 
is over! The show is 3 weeks from tonight. 


Day 7, August 27, 2000 


We started off the day with John telling us his plans for how far we should 
get today. All seven programmers were here today so we all could work just 
on our own desks. We started building simple cues, and then we hit another 
huge sequence. For the “Fire” section we had to have all the lights move from 
the north to the south of the field. They had to move in a 40-meter wide 
chunk. It had to look as if this “chunk” was moving down the field. This 
sounds simple until you think about fading in and out lights five at a time 
and doing this across four desks. Everyone started trying to figure out the 
best way to do this and we were getting no place. Finally I got out a piece 
of paper and charted it out. It ended up taking 20 cues each with various 
groups of lights fading in and out. I then called out all the lights for each 
cue and whoever had them on their desk would enter the correct information. 
Once we finished this, then we had to apply the timing John wanted (40 sec- 
onds to center and | minute from there to the end). Finally we could run the 
cue. This minute and half cue took about 45 minutes to write. We are all 
learning the best methods for programming on multiple desks. Thank good- 
ness that John is calm and has the ability to look at the big picture. This 
means he has to look at seven WYSIWYG screens at one time and envision 
what the real cue will look like. We can turn multiple (or all) lights on one 
WYSIWYG, but this just gets really busy on the screen with too many 
lines. (Figure A.4) 

We then continued onward plotting more cues. John would call out groups 
of lights and their positions on the grid. We would each use our macros to jump 
to the correct letter (section of the grid) and choose the exact coordinate. This 
method seems to work great and speed up finding positions. Late in the day we 
also built a combined color look where we each used four colors across four 
pools on the field. John then said that on each side of the field he wanted alter- 
nating colors from each programmer and then the inverse from the other side of 
the field. 

Two ideas I had to make large group programming sessions easier in the 
future is to (a) have a sign like the post office (now serving #) and use as 
now building cue number and (b) have a large wipe board in the room for chart- 
ing out these large coordinated efforts. 
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FIGURE A.4. A WYSIWYG screen displaying output from all consoles. 


Day 8, August 28, 2000 


Another day of WYSIWYG. We are now over 180 cues and just about to the 
athletes’ entrance. Today we all had the same feeling...we are ready to get onto 
the real rig. This much WYSIWYGing with just sections of the rig really 
removes us from the big picture. The renderings we do every night of the entire 
rig help. However, it is still hard to watch the rehearsal videos and realize that 
it is the same big show we are lighting. On Wednesday we move into the 
stadium and it should all come together for us then. 

We built some other big coordinated cues and have found an important 
key...we write down exactly what John says he is looking for and then we 
brainstorm. This way there is no confusion later as to what he wants. John 
also seems to now see that he has to think about the time it takes to build a coor- 
dinated cue (all lights fade up from center to out) versus the end result for the 
show. Many times it may be better to not take the time to build a huge cue that 
may be too subtle for the audience or TV. 


Day 9, August 29, 2000 


Today was the last day at Spectak working with just WYSIWYG. We started the 
morning building cues. We all charted and made the map of Australia by 


158 Appendix | A Sydney 2000 Olympic Games Journal 


combining all desks. This cue looks really cool when you see the lights form the 
outline. Next Compaq came in and did a big photo shoot that took too long. They 
are supplying the computers and monitors we use for WYSIWYG. After lunch we 
built more cues and had several other coordinated cues. These went much better as 
we all have the routine down now. We then went though all our cues and noted 
which focuses we are using. Of the 145 original positions on the grid, we are 
each using about 33-35. We also have each created an additional 70 custom 
positions. Since we have charted this, we will only update the focuses we used. 
When we start programming in the stadium, we will still have the WYSIWYG 
hooked up. We can then see if we use a palette that we have not updated on the 
real rig yet (it will be off in WYSIWYG, but not the real lights). The next two 
nights we will be updating positions and then start in with rehearsals. 


Day 10, August 30, 2000 


Well, we started in the stadium tonight. It was quite a sight to see all seven desks 
lined up in the center of the audience! We set off updating our positions. We sent 
Dave down to the field to mark the positions with cones (witches hats). We then 
started to focus the positions that we actually used in cues. The plan was to 
have each person do each position so that we would not put too much light on 
the field. This did not go well as some people did not like waiting, so we started 
doing multiple positions at a time. This worked okay except that it was not 
completely dark on the field. There were sports lights on for the crew putting 
down the flooring and working on the stage. This became a problem for me as I 
have 30 of my lights on the extreme ends of the truss. With the throw distance, 
they are very difficult to see. Since I am on the opposite side of the field, my lights 
are harder to see than those on the same side as us. Rohan has his fixtures on the 
other side too, but they are all near center. I became somewhat frustrated because 
some of the programmers were not respecting the darkness needed for me to see 
my fixtures. I had to repeatedly ask them to not work on washes, audience lights, 
etc. Their lights had no dim problems and they did not understand. I just put on my 
headphones and tried to get over it. Hopefully tomorrow we will get some dark 
time. Plus, right now the real floor is not down and Dave is measuring the positions. 
I am sure that we will have to update them all again (and again). We have a great 
vantage point for the show (dead center), but with all our monitors it is kind of 
cramped. We are supposed to get some flat screens in and that should help. Oh 
yea, we also discovered that WYSIWYG had the zoom backwards so we had to 
invert the zoom data in all our cues. 


Day 11, August 31, 2000 


Second night in the stadium. Tonight was pretty much the same as last night. 
Jo and Dave had worked out a good system for placing the cones and this 
helped. They had part of the flooring down (carpet actually), but it was placed 
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the wrong way around. Dave got a little confused at one point where it 
measured differently than the floor was marked. We will have to wait until 
the floor is down to really know for sure if everything is correct. I ran through 
my cues and WOW it looks good. When focusing one light at a time I was 
losing site of the big picture. I really was not seeing great levels of light; how- 
ever, once I ran the cues and saw the pools form. I could really see the big 
picture. The production is so huge that we are running into other problems 
too—that is, we have not had dark time yet because there are others working 
on the stage and the floor. Also, the lighting techs are shutting down our fix- 
tures and leaving at 2 a.m. so we have to stop. We have asked to have techs 
waiting until we are done so that we can work longer. Tomorrow (Friday) is 
our last day off until after the show. We start again on Saturday with rehear- 
sals. Tonight we also finally got to see the cauldron light and rise up the sta- 
dium. This is going to be a really cool moment when it happens. It is supposed 
to be a big surprise, but I just saw shots on TV from last night’s rehearsal. 
They even mentioned the “laser lights” referring to the Space Cannons. Oh 
yea ... also I spoke with Megan and told her about the lamp strobing and 
boosting on the Studio Beams. She then put all 250 fixtures in the lamp strob- 
ing and it was great! 


Day 12, September 1, 2000 


This was our last day off until after the show. We start tomorrow working for 
14 nights straight. We got a VIP tech tour of the Sydney Opera House. 


Day 13, September 2, 2000 


Today was the first day of rehearsals. Also, it marked the first time we arrived 
since lockdown had started. We had to go through security to get in. It was still 
daylight when we arrived (5 P.M.) so we went and had dinner. Then we started 
working with our fixtures trying to run some cues while the performers were 
rehearsing “Nature” and “Tin.” We had the entire rig and the sports lights 
were off. However, the Halide Metal Inert gas (HMIs) still had no scrollers 
on them so now we had our own white light to fight. We parked the HMIs 
at 0, but then the techs told us that there is a heat shield problem and that we 
have to leave the shutters open. So now we had to leave all our HMIs open and 
in white on the field. This made it very frustrating for everyone as we really 
could not do any work. Finally when rehearsal was over, we were able 
to power down the HMIs and we could finally have dark time. This 
was the first time that we had dark time in the stadium. We all started checking 
positions. Also, Dean finally had all his space cannons working and was able to 
update his focuses too. So again we all had to share the darkness and respect 
what the others were doing so that we could all see. We had Jo and Dave 
lay out cones for the “Horse” rings and we all touched up those positions. 
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We then ran the cues (Dean blacked out for us) and they looked GREAT! It was 
super to see all four desks form the Olympic Rings and then morph into pools. 

On the way back to the bus we hopped a ride in the back of a police paddy 
wagon! We all climbed in the cage and the door was locked shut. 


Day 14, September 3, 2000 


What a wasted day. We had to show up at 4 p.m. today for the techs. The sun 
was out so we did not do anything until later. Once it was dark out we could do 
things, except that it was protocol rehearsal. This is lit in solid white light and 
takes a long time. This includes the volunteers and the athletes’ parade. So we 
sat there doing nothing most of the night. Once we got to a point that we had to 
do something, the Strand network failed and we all had no signal to our lights. It 
turned out that a UPS was unplugged and we were running all day on the UPS, 
but it finally died. At about midnight we finally had dark time again and we 
were able to finish our positions. Jo and Dave mapped out the “Arrival” 
rings and we all placed all our lights on each of the rings. We also touched 
up some other focuses. Dean went down to the field to program the Space 
Cannons. The HMIs will not be ready with their scrollers until Tuesday, so 
on Monday we will not do much either. Then we will start on Tuesday with 
late nights plotting cues. 


Day 15, September 4, 2000 


Tonight we rehearsed “Nature” and they did it in full costume. It was nice 
to see the show start to come together. We ran our cues, but we dimmed out 
the HMIs as we did not have the scrollers. Dean had about half his Space 
Cannons working and was doing the color washes on the field. John had a 
camera and a monitor so he could check how it will look on camera. Dean 
had a great amber wash on the floor that looked great to the eye, but was 
really dull on camera. When asked if he could make them redder, he said 
the amber was as close to red as they can get. This will mean that we 
may have to alter some cues to try to compensate. We stopped early to 
let the crew work on the HMIs. We watched a full rehearsal of the cauldron 
and this was incredible. Tomorrow we start working from 6 p.m. till 5 a.m. 
and hopefully will get everything to work and are able to work on our cues. 
Megan has started adding in cues for the audience lights (she now has about 
eight). 


Day 16, September 5, 2000 


Tonight they rehearsed part of “Tin” and then “Arrivals.” “Arrivals” is the section 
where the people form a giant map of Australia and then 2000 children run into the 
map. It was great that once the people formed the map (before the kids ran in), the 
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FIGURE A.5 The number titled “Nature” as it appeared during the show. 


director stopped them and made them stand in place while we focused all 300 
Cybers on them. After “Arrivals” they rehearsed the athletes’ entrance again. 
This took about an hour and we all just took a break. After that the field was 
ours. The director of “Tin” came up and sat with John and we all plotted cues. 
When we would build a look then John would say “feed the machine cue 160.” 
We finally had all the scrollers working today, although each one could crash at 
any time and this is somewhat worrisome. Dean reverted back to a crew person 
to get all the Procon gear working and Brendon took over programming the 
Space Cannons. We had to stop at 2:30 a.m. because the bomb sweep was going 
on. Tomorrow we are starting the long hours. The stage crew had to rip up the 
flooring and pull all the plywood they put down as it was becoming a real mess. 


Day 17, September 6, 2000 


Tonight we rehearsed “Deep Sea Dreaming.” This number is very amazing. 
There are fish flying all over the place. We also watched the horses rehearse. 
After the cast left we sat and programmed the end of the show (speeches, 
etc.) and watched the cauldron again. We are all running into a few problems 
where we will alter a cue and we must think ahead to the next cue and not 
destroy our tracking. Each of us have run into situations where we edit one 
cue and then find we have ruined another by changing a focus in the first 
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cue that tracked into the next cue. To prevent this we are trying to remember to 
load state and update cues before altering prior cues. Jo and Rohan Thorton 
went up in a helicopter to check the Space Cannon and audience cues from 
that camera point of view. There are still many problems with the HMIs and 
scrollers. Hopefully this will get worked out soon. 


Day 18, September 7, 2000 


We rehearsed the end of “Eternity” tonight, which is when most of the cast from 
all the sections comes out on the field. This was the first time they ever 
assembled everybody and they spent time learning new choreography. After 
that the horses rehearsed again. We adjusted and rehearsed our cues. After 
rehearsals we plotted cues for the torch entries and the cauldron. We then all 
left and let Brendon have some time to get his positions built. We still have 
HMI and scroller problems. 


Day 19, September 8, 2000 


We saw “Awakenings” for the first time. This section has a large Aboriginal 
cast. They rehearsed part of their number, but I do not think they rehearsed 
all of it. Next we rehearsed with the horses again. We had to modify our 
horse rings to the actual rings they were making. John rebuilt the first few 
cues several times before landing on the HMIs during the horses’ entrance 
and the Space Cannons for their exits. Next we ran through most of the cues 
and made adjustments from John’s notes. Tomorrow is the first dress rehearsal 
with an audience of 110,000. It will be the first time the show has been run in 
order in its entirety (except the cauldron). The scrollers and HMIs still were not 
all working, but TV likes the splotchy white areas, so now we will have to 
build in some of the “messed up” looks that we have had due to equipment 
problems. 


Day 20, September 9, 2000 


We had the first ever run through of the entire show and in front of 110,000 
people! Lighting-wise we had no train wrecks or major problems. John has 
his work cut out for him on getting the lighting correct for TV. Often during 
the rehearsal he was trying to add more light and the TV people kept trying 
to adjust. They ended up just fighting each other. At the end of the night 
they had a big meeting and worked everything out. 


Day 21, September 10, 2000 


Tonight was another first...we had the stadium all to ourselves to work on 
cuing. There were no other rehearsals and we had a great night of plotting. 
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John had several of the directors come up and we rebuilt the cues for those 
sections. We had one camera on the monitor so we could watch the levels. 
Everyone really liked our horse ring cue last night, except that it was not bright 
enough for television. They want to do an aerial shot as we build the rings as the 
horses form them. We had originally built this 30-part cue using 10 lights from 
each console in each ring. We decided to rebuild these cues and use 40 lights 
from each console per ring. We also decided to only use the lights closest to the 
ring. So Rohan and I had 3 rings and Vickie and Jason have 2 rings. Also, 
Rohan and I tried to make them so that the dimmer lights (without narrow 
lenses) are closer than those with narrow lenses. This made mine somewhat 
difficult as I had fixtures in a wacky order. The rings read very well now on 
the camera and we all feel really good about this (now) 40-part cue. Tomorrow 
we will start again with rehearsals of some sections and rebuilding of some cues 
for “Arrivals” and “Eternity.” 


Day 22, September 11, 2000 


We started the night watching while the band rehearsed their entrance and exit. 
This sounds quick and easy, but with a marching band of 2500 it is no easy task. 
During the wait, Vickie and I got to hold a real Olympic torch. It was not heavy, 
as we had been told. After that we rehearsed the horses again. This time all 400 
were wearing in-ear monitors so it made it difficult to know what they were 
doing. Our new improved horse rings look great. The problem now is that 
the horses do not form the same rings every time. Because the TV crew 
plans to do an overhead shot (which looks great) we are going to get our 
rings looking great and let the horses look like they did not form them correctly. 
We also watched the cauldron again and the TV crew rehearsed their shots. This 
is going to look super on television and in-person. After the horses, we plotted 
more cues and started some cleaning up of cues. Tomorrow we will do a tech- 
nical rehearsal and go through all the cues and do “housekeeping.” 


Day 23, September 12, 2000 


Tonight was a technical rehearsal that went on till about 1:30 a.m. when it 
stopped due to technical errors. We actually saw some new flying elements 
for “Tin” that we had never seen. We also found out that our horse ring cue 
has been cut. All the work we did is now gone. Oh well, maybe it will get 
added back in. After the rehearsal ended, we all plotted cues for several more 
hours. John is having a tough time with various directors, television people, 
artistic directors, and so on all giving their input to how they think the lighting 
should be. We are continually making changes to most of our cues and trying to 
keep up with all the tracking information. Tomorrow is another dress rehearsal 
and we are all looking forward to it. 
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FIGURE A.6 The number titled “Fire” as it appeared during the show. 


Day 24, September 13, 2000 


Tonight’s dress rehearsal in front of 110,000 went very well. Everything ran 
extremely smooth up until “Eternity.” This section needs a lot of work in all 
areas, not just lighting. TV liked most of the show and we just need to balance 
some of the images to get rid of hot spots, etc. Rohan Thorton has been very 
good about filling us in on all the politics currently going on. The television 
director will say the segment looks great, but he wants to light the people exit- 
ing each segment so he wants us to hold the lighting looks longer. The segment 
director will want to relight the entire number with new colors, pools, and so on. 
The artistic director wants to get the transitions happening sooner so that we do 
not see the people exiting. Each of these people come to John and voice an opi- 
nion. He has to try to figure out how to please everyone (and himself). If he 
makes the changes for the segment director, then the television director com- 
plains and vice versa. Rohan has asked that we all try to make “commonsense” 
decisions on our own and modify looks that we feel should be modified. This is 
a usual thing for programmers to do and most LDs just never know it happens 
or take it for granted. This is fairly easy for half the programmers, but the four 
of us with the bulk of the Cybers have to act as one. If one of us changes our 
Cybers to 60% then it looks funny if the other 3 desks are at 100%. So we all 
just talk and decide what will be best. 
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After rehearsal we did a cue by cue run through to do “housekeeping” on all 
our cues, setups, etc. We worked until 5 a.m. John had left to light a building 
downtown, so Jo called us through the cues and gave us John’s notes. Tomor- 
row we will go through all the cues again with John and Rohan and modify all 
levels for television. 


Day 25, September 14, 2000 


Tonight we worked until 6 A.M. cleaning up cues and rebuilding “Awakenings” 
and “Eternity.” We had to stop working for more than 2 hours while they 
rehearsed with the torchbearers. Their identity is supposed to be kept secret 
so we had to leave it dark during the entire time. We all feel that we have a 
fantastic show and are ready to run the show tomorrow. 


Day 26, September 15, 2000 


WOW, what a super show! We all had a great time and everything worked per- 
fectly. We made a few live adjustments and that added to the fun. We were able 
to watch the TV show on a monitor in front of us while watching the real show 
at the same time. It looked super! Even the segments and cues that we rebuilt at 
4 a.. the night before looked incredible. The crowd enjoyed the show and see- 
ing 110,000 people wave their flashlights in the stands was awesome. Vickie 
and I cheered on the U.S. team as they entered and then we all cheered for 
Australia. Then it was time for the lighting of the cauldron. This was going 
great until the trolley got stuck and the cauldron did not move. This was a 
very scary moment for all of us to see this huge moment almost not work. 
After what seemed like forever (actually was about 3 minutes) the cauldron 
made its way to the top. The crowd still loved it and everyone was thrilled. 


< TIME OFF DURING THE OLYMPIC GAMES > 


Day 40, September 29, 2000 


Tonight we went back to the stadium to begin working on the “Closing.” The 
crew was in last night to check the rig. Everything was working well. Vickie has 
flown back to the States and now Gooch is programming her desk, also Robert 
Bell has gone home. We first sat down with John and discussed his plans for the 
show. We then formulated the best way to lay this out on the consoles. We 
decided to set it up much like a rock show and make different pages for each 
song or segment of the closing. This way we can have bumps, chases, and so on 
specific to that song. We will each have a master cuelist on a template 
page and then add in the other cues via the separate pages. Gooch and I 
also have two faders for HMIs on the template page. In addition, we have 
to be ready to throw in anything that John calls out. Basically tonight we 
roughed in some positions with the sports lights still on. Tomorrow we 


166 Appendix | A Sydney 2000 Olympic Games Journal 


. = a eeeeeee ‘ = - 
wnt yee ee eprrerey 


a 


FIGURE A.7_ The number titled “Tin” as it appeared during the show. 


will have it darker, but still not complete darkness. Then on Sunday we see a 
daytime rehearsal and then run the show for the world that night. There is 
very little setup or rehearsal time. One good thing is that we will get in ear 
monitors of the music so we can do things on the beat. Things went well 
until they turned the power off on us at 4:30 A.M. 


Day 41, September 30, 2000 


When I walked into the stadium they were playing the U.S. National Anthem. It 
was a medal ceremony and the United States had won gold. This was great to 
walk in and cheer on our winners, and they were just down in front of me too. 
We started working sometime after midnight and worked through the night till 
almost 6 A.M. We never had any dark time, as they were building the stage and 
had sports lights up all night long. We managed to plot cues for about half the 
songs. We also prepared “wing it” masters and palettes for the rest of the show. 
John has notes on what he wants to do; we just do not have cues for it. Tomor- 
row we have a rehearsal in the daytime and then the show starts. We plan to 
update positions on the stages during the preshow, as this will be the first 
dark time we have with the stages in place. One interesting thing is that this 
is the type of show that is easy for a programmer to just wing it, but since 
the rig is spread across eight consoles this is now difficult. If I decide to 
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throw in a random strobe at a point in a song and no one else does, then my 
lights look like they are doing the wrong thing. So we all just have to count 
on John to call what he wants and that is what we will do. We went home, 
had about 4 hours sleep, and now go back for the rehearsal and show. 


Day 42, October 1, 2000 


We went in at noon and the stage was still not built. During the day they built 
the stage and we sat around. We never actually rehearsed anything. Doors were 
at 4 p.m., but they held them till about 4:30. Even then, they were still building 
the stage. Around 6 p.m. the marathon runners came in, and then at 7:30 was the 
preshow. This was our only time to update positions. The show started at 8 P.M. 
We all turned on “live programmer” and off we went. We had preprogrammed 
about half the songs in the show and the rest we just made up as we went along. 
During the show John would call “stand by for all Cybers on stage in blue from 
east and magenta from west ... Go.” We all also improvised during most of the 
songs using the “wing it” stuff we had premade. The show looked great and 
John was very happy. He was thrilled that many times we all just took over 
and made the show happen and then he would call just the major changes, 
etc. Mark Hammer did a super job with the fixtures on the stage and we all 
had a great time. 


FIGURE A.8 A moment from the Closing Ceremony. 
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TABLE A.2 Sydney 2000 Olympic Games Lighting Equipment 


3,288,960 Watts 
111,169 Meters of Cable 
64,775 Meters of Power Cable 
52,260 Man Hours 
46,394 Meters of Data Cable 
14,208 Channels of DMX 
13,704 Amps Single Phase 
7054 Cables 
4568 Amps Three Phase 
4535 Power Cables 
2519 Data Cables 
1628 Total Fixtures 
970 Automated Fixtures 
658 Analog Fixtures 
541 Meters of Truss 
300 HES Cyberlight Turbo 
207 Racks of Power Distribution/Dimming 
200 De Sisti Ducci 
136 HES Studio Beam 
132 HES Studio Color 
112 ACL 
111 Kilometers of Cable 
106 Lighting Crew 
100 4 kW HMI 
a9 Tons of Equipment 
92 Kino Flow 
90 Rigging Points 
78 Chain Motor 
76 DMX Splitter 
60 Par 64 
57 Mains Connection 
48 7k Space Cannon Ireos Pro 
40 HES Cyberlight 
35 Streams of DMX 
34 Tons of Cable 
28 Space Cannon Easy 2000 
22 40 Foot Trailers of Equipment 
18 2k Lycian Followspot 
14 Wholehog II 
11 Weeks On-Site 
8 4k Space Cannon Ireos Pro 
8 4k Lycian Followspot 
4 Lighting Suppliers 
2 Strand 550i 
1 Opening Ceremony 


il Closing Ceremony 


Metallica Touring Journal 


FIGURE B.1_ Metallica 2003 Summer Sanitarium tour. 


The Metallica tour was a fun and exciting time in my life. Not only did I get to 
tour the world and run lights for a legendary band in front of thousands of peo- 
ple, but I also was exposed to many different circumstances and opportunities 
along the way. During the year and a half of working with them, I worked on 
numerous consoles, different rigs, festival shows, and more. It was like a crash 
course in lighting with various crews, daily troubleshooting, and constant 
updates and programming. On top of all that, I was able to make friends 
with the crew, fly on private planes, lose lots of sleep, and generally enjoy 
the touring lifestyle. 

Throughout the tour, I kept a journal of my experiences. Looking back at the 
journal I can see valuable information about working on a mega tour, preparing 
for festivals, busking shows, and general troubleshooting. What follows are 
some of the most important entries from my journal. 
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JANUARY 2003 


John Broderick (JB) (the band’s LD for over 20 years) told me that Metallica 
was getting ready for a big summer tour and he wanted me not only to program 
it, but also to operate it on tour. 


FEBRUARY 2003 


John Broderick has informed me that he will be unable to tour with the show 
this year. He has hired Butch Allen as Lighting Director to call followspots 
and generally be in charge of the lighting. I will still act as programmer and 
operator. 


APRIL 2003 


There will be two stages and rigs that “leap frog” from venue to venue. In fact, 
there will be two of everything except guitars! In addition, as we will be in 
Europe for the weeks leading up to the summer tour, John plans to hire 
Troy Eckerman as an additional programmer. Troy and John will work in a 
WYSIWYG studio preprogramming the tour. Then when the preproduction 
begins in Detroit they will continue refining the cueing. Once we return 
from Europe, we will have only a few days to learn the rig and cueing prior 
to the first show. 


MAY 22, 2003: SAN FRANCISCO 


Lighting for Metallica is about knowing the music extremely well and being 
right there with the band on hits, riffs, and so on. You can not let the band 
lead you; rather you must be perfectly synchronized with them. JB can do 
this because not only is he a super LD, but he also has worked with Metallica 
for 20 years. This is where our big challenge comes in, trying to learn 40-60 
songs meticulously. 

Butch and I both had moments during the show where we hit the bumps at 
the right place, perfect with the band. In addition we had our mad flailing 
about in which we just tried to survive the song. We realize we have a lot 
of timing to learn so we will listen and chart all the songs before the next 
show. At least now we know and understand what we are listening for within 
the music. 


JUNE 8, 2003: GERMANY 


I loaded my disks and looked for errors. Sure enough, some fixtures were hung 
the wrong way, and some of the dimmer patch had changed. I made these 
changes and added in the additional strobes and bits for the TV shoot. During 
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the day, I did more preparing for an upcoming Italy show. Using HogPC, I built 
a show with all the possible versions of fixtures on their plot. Then I cloned cue 
data so I will have a base to work from. 


JUNE 9, 2003 


I spoke with Troy Eckerman today. He is working with JB on the US tour rig at 
JB’s house and they have a WYSIYG system setup. They have just begun and 
have a goal of 30 songs (3 a day for 10 days). 


JUNE 10, 2003: PARIS, FRANCE 


This morning we went on site surveys of the three clubs we will play tomorrow. 
The first has about 16 conventional lights and a standard desk. The second has a 
big old conventional desk, and a Scan Commander with about 16 moving 
lights. The third is much like the first; in fact the same lighting guy will be 
there and will bring the same console from the first gig. We are adding strobes 
to all three shows and some followspots to the second. 


JUNE 11, 2003: PARIS, FRANCE 


Three shows, three venues, one day! 

We walked into the first club at about 8 a.m. Butch and I quickly took over 
the small lighting rig. We had suggested gels the day before and the local light- 
ing guy had everything in for us. Then I learned the process of recording sub- 
masters on his desk and quickly built a layout of bump buttons. Once the 
backline was set up we did a quick focus of the lights. Then it was time for 
me to go to the next club. Butch would stay and run this first show at | P.M., 
then come over to the second venue. 

I arrived at the second venue and found our lighting guy there and told him 
what I wanted to do. He had also already gelled the fixtures per our request and 
set up some floor fixtures. I quickly learned this lighting guy was not worth 
much. I had to “babysit” him to get him to do anything. If I asked for something 
and then I went to do something else, he would disappear. The generic lighting 
console at this gig was a mess and the stoned lighting guy was not proficient 
with it. It took forever to create the layout and patch I wanted. Then when 
the strobes arrived, he ended up messing up most of what we had done. I pro- 
grammed some stuff into the Scan Commander and focused the conventionals 
over the stage. About that time, Butch arrived from the first gig. Butch ran the 
conventionals and called spots, while I ran the Scan Commander. Right after the 
gig, we got into a van and were rushed to the next venue. 

The third gig was at a small club, with a very strange shaped stage and audi- 
ence area. We had a small amount of conventional fixtures, plus our added 
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strobes. In addition, we added two small vertical trusses on the DS edge with 
some sidelight. They had brought over the console from the first gig, so I 
quickly re-programmed the submasters to work with this system. Then we 
did a speedy focus. 


JUNE 12, 2003: IMOLA, ITALY 


The cloning I did to prepare for the show worked very well; I just needed to 
update positions, and colors for the automated lights, and add in the conven- 
tionals. I also merged in the patch from the festival guy’s disk. 


JUNE 14, 2003: NIJMEGEN, NETHERLANDS 


I loaded my show disks and started checking things. On the automated desk, 
I had to update my positions due to the low trim and the fixtures hanging 
differently. Once everything was focused, Butch and I began to go through 
the cues to make some color changes we had discussed. I soon discovered 
that a “cheat” I did in Germany a week ago was affecting me now. On the 
conventional desk I had built some simple cues with a single color for the scrol- 
lers. Then I placed each cuelist on a corresponding page. In this way I “cheated” 
as I used the same basic 6 cuelists across all 16 pages. Well, when we wanted to 
change our color scheme, I had forgotten what I had done and just started 
updating these cues with the new colors. As we changed pages, I found the 
reoccurring cuelists were now a problem. I had to quickly build an individual 
cuelist for each page. 


JUNE 15, 2003: NIJMEGEN, NETHERLANDS 


The sun was shining bright on the stage during the changeover, so I could not 
update any positions. I used my binoculars to look at the fixtures and see if they 
were pointing in the general direction. Butch was on stage for a bit and called 
focus for me on the drum specials. Everything else would have to wait until it 
got dark in the middle of the set. 


JUNE 17, 2003: BARCELONA, SPAIN 


JB sent us some show files that he and Troy had built. I sat in my hotel room 
and listened to the music and pressed the GO button on HogPC. The cues seem 
pretty straightforward, but I am wondering how different it will be with the 
actual live band. Tomorrow I will try with the show recordings I have. Some- 
time this week I have to preprogram the Madrid show, as we arrive at that 
festival after it has started. 
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JUNE 20, 2003: BARCELONA, SPAIN 


I received new “finished” show files from JB and Troy. They completed 
16 songs. Over the next two weeks I will listen to the music and press the 
GO button on my HogPC to rehearse the cues. 

At this show, the patch was very different and they only had one Wholehog 
II with wing. However, they were able to squeeze all the conventionals onto the 
four universes, so I could run everything on one desk. I spent a couple of hours 
adding in all the conventional cues and updating my positions. One of the best 
things on this tour has been the console’s ability to merge data. I just load my 
show, then merge in the patch and groups from the test show the crew made. 
Then I can quickly use their conventional groups to build our cues. It is strange, 
as often I do not even know what the fixture numbers are; I am just using 
groups. 


JUNE 22, 2003: MADRID, SPAIN 


The rig here is the same basic European plot we have been using. Except 
the VL2416s are replaced with Studio Color Ms. I spent about three hours 
re-building the show. I had to again merge patch information and combined 
the two desks so that conventionals and automated lights are on one desk. 


JUNE 25, 2003: ROSKILDE, DENMARK 


Today I spent some time in my hotel with HogPC preparing for the Copenhagen 
show. It will be a very different rig than all the others. They emailed me 
drawings, plots, and patch disks. I first loaded my last automated show and 
then I added in the new fixtures. This rig has Mac2ks and Cyberlights instead 
of VLs and Studio Colors. Then I merged in their patch and started cloning the 
palettes and cue data. We will go in tomorrow morning, but again I will not get 
a chance to look at everything until show time. 


JUNE 26, 2003: ROSKILDE, DENMARK 


There is a bug with HTP faders and MIDI on the console that is really bugging 
me. To get around this problem, I had to reorganize much of the show layout. 


JUNE 29, 2003: DETROIT, MICHIGAN 


Both stages were set up in the stadium facing each other (see Figure B.2). There 
were two FOHs in between the stages. JB and Troy were working on one 
system when I arrived. I sat and watch them update cues and learned the rig. 
Tomorrow we will begin the “handoff” procedure with JB and Troy. We will 
rearrange the layout to better suit our playback needs and begin rehearsing 
our cues. 
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FIGURE B.2 Two stages together in Detroit. 


JUNE 30, 2003 


Since both stages were set up, someone had an idea to have the band play on 
one stage, while watching the other. So we MIDI’d the two systems together so 
that the lighting cues would happen on both at the same time. It was pretty cool 
to run lights on a rig and have a full backup rig right behind me! During the run- 
through, JB had Butch and I run the cues. In addition to him yelling cues over 
the com, the sound guys were busy tweaking the system. They would isolate 
certain microphones so it was very hard to hear our cues since we were missing 
most of the music. 

Once the rehearsal was done, Troy and I began the task of moving things to 
the wing, creating template information, and so on. We basically prepared the 
show for the real playback scenario. When we finished this, Butch and I ran 
cues for some songs before calling it a night. The cueing is difficult in places, 
but much of it is just figuring out where it is intended to go. Then once we know 
that, we just have to work on our timing to get it right. 


JULY 1, 2003 


After rehearsal with the band, Butch, Troy, and I attacked the notes and were 
really having fun going through and fixing the cues. It was great to be on a con- 
sole next to Troy. We would share tips, habits, and both learned from each 
other. It is always a joy to work with another programmer and discover more 
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methods of programming. JB came back after a couple of hours and said he 
liked what we were doing. We asked some cueing questions and he ran a bit 
of a few songs to show us. 

After JB left for the evening, the three of us continued our process of 
“re-building” many of the looks. We went through JB’s notes and made 
changes to the songs (make them brighter, change colors). Then we would 
run through the song and move on to the next one. 


JULY 2, 2003 


Upon arrival we began working on the cues, building new cues, and researching 
a console-crashing bug. I finally found the cause of the crash, and removed it 
from the show. JB said he will call spots, while I run the board and Butch 
runs the wing. I thought I did pretty well even though there were a few places 
I got lost, and some cues I missed. During the show JB was busy calling spots, 
giving lighting notes, as well as video notes. 

The rest of the evening, Butch and Troy worked on cues while I sat with 
show recordings and rehearsed cues on the spare console. I took notes as to 
when the cues happen and will enter this information into the cuelists tomorrow. 
I ran every song at least three times until I knew when every cue should happen. 
After many hours, JB returned and worked with Troy and Butch to make more 
changes. I am very glad that Troy is here because during and after the show I do 
not have to worry about the programming. I am free to concentrate on the cue 
triggering and not what is going on in the desk. However, Troy is leaving after 
Friday and then I have to do both. 


JULY 4, 2003 


I planned to use HogPC to rehearse my cues before the show, but the file would 
not load into HogPC, so I went out to FOH to work. I put on my headphones 
and ran Metallica cues, while Limp Bizkit was playing on stage. Troy left 
tonight, so now it is all on me to finish all programming and notes. 


JULY 8, 2003: EAST RUTHERFORD, NJ 


I spent a good part of the day rehearsing my cues. The show went very well. JB 
said we did a great job and that he could leave it to us without worry. We even 
ran “One” without any assistance from JB. Afterwards he complimented us on 
how well we did that song, but also reminded us it was still not “perfect.” 


JULY 12, 2003: PHILADELPHIA, PA 


We had to go through the entire show and find color bumps that worked with 
the backdrop. The problem though was that we could not see the backdrop 
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fixtures, as the daylight was too bright and many of them are floor fixtures that 
get placed at the changeover. So, we had the crew set up some fixtures and a 
console with wing under the stage. Then Butch and I spent two hours working 
on the cues, adding new bumps, changes, and so on. 


JULY 17, 2003: WASHINGTON DC 


This was the first dark time we had with the rig since preproduction. I loaded 
the original Detroit show into the backup console and the current show in the 
main console. Then we could use the data backup switch to swap between the 
old and the current focuses. We looked at each to see what had changed and 
decide if it was a good or bad change. Some focuses I would rebuild to 
match the Detroit show, while others I would just touch up a bit for this venue. 

Next we began going through the cues to make changes requested by man- 
agement. Basically we were looking at the set lighting and adding it where it did 
not exist. Due to the short amount of time allotted to us, we only completed 
about four songs of the show. 


JULY 18, 2003 


After I completed my notes from the previous show, I downloaded new soft- 
ware for the consoles. I installed the software in the backup consoles, as it is 
supposed to solve a crashing problem when no wing is attached. I will leave 
the current software installed on the main desk, and only run the new software 
on the backup desks. Butch is very nervous about changing O/S, but I have 
assured him that it is in the backups only. 

During the day Butch was very nervous about the new software. I ended up 
putting back in the current software and agreeing to not use the new software 
until I test it more tomorrow. 


JULY 19, 2003: COLUMBUS, OH 


After I did my notes from the night before, I installed the new software in the 
backup consoles. Next I ran every cue in the show from the main console, with 
MIDI triggering the backups. Finally, we hooked up the wings to the backup 
system so Butch could push buttons and feel good about the backup software. 
Even with this, he is still nervous about the new software. Fortunately, during 
the show the new software worked like a charm in the backup desks. 


JULY 25, 2003: ST. LOUIS, MO 


Butch has been busy advancing the European shows. It looks like it will be a 
mix of rigs again. A few might be loosely based on our last European plot, 
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but with different equipment (HES instead of VL). I will again have to quickly 
adapt each rig to our base model of operation. 


AUGUST 15, 2003: SALZBURG, AUSTRIA 


It was very odd to go back to our festival programming after the big Sanitarium 
tour. During the show, Butch and I replicated some of the cues that we became 
so familiar with. Of course, we did not have the same fixtures, so often it was 
not possible. The band played the same set-list, which was great, although it 
was odd not pressing the GO button all the time! 


AUGUST 16, 2003: KONSTANZ, GERMANY 


The stage and lighting rig are very small. There are 24 moving lights and a 
bunch of par cans. After last night’s show I prepared tonight’s show file on 
HogPC. When I went into the gig, I simply merged in the patch and checked 
that everything was working. I actually stood on stage and did my work with 
a console minus a wing. I also decided what to do with the front truss fixtures 
and reorganized some of the show. Since the wing was at FOH, I had to check 
all the wing stuff using virtual masters. 


OCTOBER 27, 2003: AUSTIN, TEXAS 


Butch has been working with the Japanese crews on the plot and budget for the 
show. He has drawn a plot that is a modification of the Summer Sanitarium rig. 
It is basically a little smaller to fit into arenas. This means we will be using the 
same show file as before, but I will need to update positions and so on. Plus the 
7K Syncrolights are changing out for 3Ks, so I will need to clone all that infor- 
mation. He also told me this plot will go on to Europe as well. 


OCTOBER 29, 2003 


The Japanese lighting company does not have enough Studio Beams for us; 
instead they will provide Studio Colors. So I will need to clone the data over 
to the new fixtures throughout the show file. In addition, some of the cyc lights 
are changing as well. This is going to be a big task, as there are about 2000 cues 
in the show that need cloning of many fixtures. Plus I want to keep the Studio 
Beams in the show file as they will be back for the European show (although 
there I will have to clone the Studio Colors into Studio Beams!). As our main 
show file still will not open in HogPC, I have arranged to go to High End 
tomorrow and do the work on a desk. 
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OCTOBER 30, 2003 


I spent about four hours at HES cloning data and getting frustrated. The show 
is so large (and with double the fixture count due to cloning) that the desk is 
moving very slowly. I know I need to save often, but even that takes about 
seven minutes (it is a 3 disk show). After I cloned all the palettes, I began work- 
ing on the cues. I was averaging about 30-40 minutes a song. With 28 songs in 
the desk, this would take a while, so I decided to try to mend the HogPC 
problem. I spent some time correcting the library problem that prevented the 
show from loading into HogPC. Then I checked to confirm that the correction 
did not affect any other parts of the show file. I found I could clone much faster 
with HogPC than the console. I finished the cloning at home and sent the show 
files off to the Japanese crews and Butch. 


NOVEMBER 4, 2003: TOKYO, JAPAN 


As I walked in the lobby of the hotel, I saw Butch and he said, “there is a lighting 
meeting on the fourth floor in ten minutes.” So I ran to my room and then back 
down to the meeting. I walked into a ballroom that was filled with Japanese and a 
few of our crew. There were tables set up for each department and a translator at 
each table. Everyone was talking with their crews and making changes for the 
next day’s load in. This was a very impressive display of Japanese organization. 


NOVEMBER 5, 2003 


When there was power to the desks, I spent about an hour preparing things. Then 
I began checking the rig and found lots of problems with the fixtures. Luckily, the 
Studio Colors I cloned from Studio Beams seemed to be working out well with 
the positions. I had been worried they would be way off due to the differences in 
the fixture’s pan and tilt ranges. The Mac2k’s on the other hand were hung dif- 
ferently than the summer tour; all their positions were way off. I spent time updat- 
ing focuses, while the crew worked on fixing all the broken fixtures. Eventually I 
had Butch start running cues on the main desk, while I was updating positions on 
the second. This is when we found out that while much of the show will work, we 
will have some major updates to make due to fixture differences. In addition, we 
have no clue what songs the band might play. We have heard rumors of all kinds 
of old songs, for which we have nothing programmed. We do have two Buskit 
pages from the summer, but we have never used them. By midnight I had all 
the positions finished and most of the rig working. 


NOVEMBER 6, 2003 


We arrived at the gig and went straight to work at the consoles. We went 
through all the cues and tried to fix any major train wrecks. We continued fixing 
as much of the show as we could throughout the day. The show looked very 
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FIGURE B.3__ A different version of the Metallica rig. 


different and Butch and I took notes when we could. After the show we 
discussed our plan for tomorrow and prioritized the list. As we are planning 
to do a similar rig (with the original fixture types) in Europe for December, 
we have been trying to think about all the updating we need to do. Any 
major changes we make here due to the show being indoors we need to remem- 
ber to do them again for Europe. Or I could take this show and clone it all back 
again, but that make it into more of a mess. The biggest problems we have here 
are the scrollers on the moles (they used to be faders) and the scrollers on the 
Syncrolights are different scrolls. All the colors are strange and the mole 
scrollers often are scrolling all over the place. 


NOVEMBER 14, 2003: NAGOYA, JAPAN 


I have 2 weeks off from Metallica before we go to Europe. We will have to 
remember many of the notes we did as we will revert back to the summer 
show file because the rig is back to more standard fixtures. 


DECEMBER 2, 2003: OSLO, NORWAY 


Many of the Studio Beams were hung the wrong way around and the Mac2k 
were in the wrong orientation as well. Instead of wasting time and having the 
crew re-hang the fixtures, I said I would just take care of it when I update my 
positions. So I had to rebuild all my positions from scratch. 
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After I did the positions, I went through and did what notes I could remem- 
ber from Japan. Then the band did a sound check midday and we ran some 
lights for this. Butch and I did manage some other notes before we stopped 
to give the opening act some time on the consoles. 


DECEMBER 3, 2003 


The band was playing at a very fast tempo today, which made it a little more 
difficult. 

After the show I discussed moving a Syncrolight with Butch. We are 
planning to move one of the DSR fixtures to an US position. Then I will 
patch it in as a new fixture and we can add it to new cues we build. He 
wants to program cues for some of the newer songs the band is now playing. 


DECEMBER 5, 2003: HANOVER, GERMANY 


There were some strange things that happened during the show. The conven- 
tionals were flashing at a low rate due to a power problem. A Syncrolight 
decided to reset in at the start of “One” and leave a big green light on stage. 
Then a full beer cup hit Butch in the back of the head and splattered all over 
the desks. We had a quick panic as we tried to get something to wipe it all 
up. Our FOH guy took his shirt off and used that while the sound guys went 
to get a towel. All the while I kept pressing the go button as we were in the 
middle of a song. Now we will make sure we always have towels at FOH. 


DECEMBER 8, 2003: ZURICH, SWITZERLAND 


The changeover tonight had problems getting the drum riser out. Once it was 
out, I had just about one minute until the pre-show tape started rolling. 
I could barely check my focuses on the riser. As it turns out the two fixtures 
on the riser were placed incorrectly and I had to act quickly to prevent them 
from going to all the wrong places. 

The show went well. We had a few problems with some fixtures, but I 
managed to park things so the problems were not noticed. I really enjoy running 
the show as it comes fairly naturally to me now. I can really understand why JB 
pushed so hard in the beginning to get all the cues absolutely correct. 


DECEMBER 13, 2003: ERFURT, GERMANY 


Thad to re-do all the positions today due to a very low trim. Butch and I made a 
couple of specific pages for some of the new songs. They are only copies of the 
other buskit pages, but we will start creating custom cues tomorrow. Butch 
charted out “The Unnamed Feeling” and handed me a great “outline” sheet. 
Tomorrow we will build these cues. 


Appendix | B_ Metallica Touring Journal 181 


FIGURE B.4_ Butch Allen and Brad Schiller bringing the metal. 


DECEMBER 14, 2003: MANNHEIM, GERMANY 


After updating positions and checking the rig, Butch and I began to program the 
song “Unnamed Feeling”. We built about forty cues before we had to stop for 
doors. It was tough though as this venue had windows all around the stage. So 
as we were building cues, sunlight was streaming in all over the place. 


DECEMBER 16, 2003: COLOGNE, GERMANY 


Before the show we finished programming “Unnamed Feeling” and I spent a 
good part of the day practicing it. Then when the set list came, it was not on 
the list. 

The show went well and it was great to have the rig back at the normal trim 
height. Right at the start when the house lights went out, our consoles were hit 
with a big cup of beer. So during the intro music I was busy trying to clean up 
the mess. Luckily we had towels at FOH now. 


DECEMBER 19, 2003: EARLS COURT IN LONDON 


The show went well except that during the changeover I mistakenly put the 
drums special on the first song and not the template page. Butch wanted the 
correct cue back on the fader immediately. First chance I had, I switched back 
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to the template and put what I thought was the correct cuelist there. During 
the next song I found out it was also wrong! So I built the correct cue infor- 
mation and moved it there when I could. Of course, I could only switch to the 
template page between songs, so for a few songs the drum special was not 
correct. 


DECEMBER 31, 2003/JANUARY 1, 2004: LAS VEGAS, NV 


I used our same show from the first leg of festivals in Europe. It was strange to 
see this show once again. I had previously cloned the fixtures to match what we 
now had. The Joint only has 8 Cyberlights and 8 Studio Colors and they added 
in 4 Mac2k’s. 

We had a TV shoot first for one song for the FOX NYE special. Then our 
show started about 10:30 p.m. and went right up till midnight. Butch and I had 
fun with the show trying to recreate many of the usual cues from our normal 
show with the limited fixtures. 


JANUARY 6-8, 2004: AUSTIN, TEXAS 


We have about a week and a half before we go to New Zealand and Australia. 
I have much cloning to do to prepare for those shows, as many of the rigs will 
be different fixture types and we are using the main show. The New Zealand 
show has Martin gear, while the Australia shows have HES. I spent the last 
few days cloning everything into one huge show. It was easiest to clone 
everything at once than just remove the bits I need for each show. 


JANUARY 15, 2004: AUCKLAND, NEW ZEALAND 


I found a major problem with the cloning. Anytime there was a hard value for 
an HES fixture’s shutter set to open, it was cloned to a Martin light as lamp 
off. Since Martin does not use a modifier for control functions, this could 
have been a disaster. I ended up going through every cue in the desk while 
reading the output window. Whenever I found the “lamp off’ command, I 
would have to change this to open shutter. In addition, some other hard values 
for the shutter channel were incorrect for strobing. I spent the two hours of 
the band’s sound check going through all the cues and correcting this 
problem. 

There are two stages here and the FOH is in the middle of both. So my posi- 
tion is far to the side of the stage. Butch stood on stage as I updated my posi- 
tions and it was a big help due to the angle. I added in strobe cues where needed 
and fixed other cloning errors. In addition, we had to make up for the lack of 
Syncrolights. At least in Australia, we will have half our Syncrolights and all of 
our floor fixtures. 
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JANUARY 16, 2004 


There were a few cues that I had missed the “lamp off’ command so the truss 
toners went out once or twice, but I managed to strike them again. 

After the show we were talking about how much sunlight there was for the 
first hour of the show. We decided that to combat this we will use a high prior- 
ity cuelist for all fixtures to be in open white. This way we can still run the 
show, but it will be brighter during the daylight. Then as it darkens I can release 
white cuelist and add color back to the show. 


JANUARY 17, 2004: BRISBANE, AUSTRALIA 


I updated my positions and Butch and I worked on some cues. I also corrected the 
strobe problems I was aware of that resulted from the cloning. It was good to be 
back with our HES rig. The Studio Beams in the air are replaced with Studio Colors, 
the floor cycs are now City Colors, and we have four out of ten Syncrolights. 


JANUARY 18, 2004 


The show started and was going well. It was great to see the show with Syncro- 
lights again! Then right at the end of “Frantic,” everything went off!! The gen- 
erator for lighting died! We lost all fixtures on stage as well as FOH. Even our 
UPS failed! All we had were the eight followspots as they were on a different 
generator. This was good because the audio was still working, so the band played 
on. They played “Sad But True” in only spots. Then during the next song power 
was back, but we had to wait for most of the fixtures to cool so that they would 
strike their lamps. Finally by the end of this second song I had the entire rig back. 
We continued on and everything was great. Then at the blackout before “Battery” 
the Mac2k’s were locked on. I dimmed them out and solved the problem. It seems 
after the power loss and re-strike all their shutters were messed up. Luckily the 
first encore was next so I had time to reset them. 

It was fun to have the “problem” during the show and react accordingly (and 
regain mental focus after). All in all it was handled very well, except the part 
about the FOH UPS not working! Tomorrow I will test the UPS before the show. 


JANUARY 26, 2004: MELBOURNE, AUSTRALIA 


The changeover started in bright sunlight and it was practically impossible to see 
my fixtures to update the positions. We used the white cuelist for the first half of 
the show until it was dark enough to use color in the show. A funny thing hap- 
pened in “Harvester of Sorrow” when the white cue was suddenly released. 
I asked Butch if he did it and he said no. Then he said, “maybe it’s a comment 
macro.” He was right. In Europe, I had a special button on that same fader and 
there was a release comment macro in this particular song. 
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FIGURE B.5 Operating the lights in the rain. 


JANUARY 28, 2004: MELBOURNE, AUSTRALIA 


Our FOH position is beyond the roof of the venue, so they had a small tent and 
some plastic over the FOH position. This was removed before the show. 

The trim was very low, about fourteen feet for the Syncrolights. So I propor- 
tionally patched the intensity of them at 80%. This limited their output without 
having to re-program everything. 

The show started and was going well until it began to rain. The crew 
scrambled to put the roof back on FOH. We had the tarp over us with crew 
guys standing holding it up (see Figure B.5). At one point water poured off 
the roof onto the second desk. It was a good challenge to not get distracted 
by everything going on and to just concentrate on the show. In addition, the 
set list had many songs that we rarely see, so I really had to study what I 
was doing. In fact, they even played “Unnamed Feeling,” which we pro- 
grammed in Europe, but never played before. I listened to half of it before 
the show to help remind me of the song. 


MAY 22, 2004-JULY 4, 2004: EUROPEAN TOUR 


We had a crazy non-stop European tour for about six weeks. We literally had no 
scheduled days off. We did a show every other day and the off days are all tra- 
vel days. We flew a mix of private jets and normal commercial airlines, as well 
as a few bus rides. We had two different rigs; the “black” was the big Summer 
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FIGURE B.6 Another touring rig with Metallica. 


Sanitarium show and the “blue” was the December European tour rig. We also 
had a bunch of festivals with various rigs from our past. 

The tour was lots of fun with a bit of hard work and very little sleep. My 
main job (besides operating the shows) was to prepare for the festivals, 
which involved hours of computer work cloning data and organizing the 
show files. 


IN THE END 


Throughout my time touring with Metallica, I was able to learn quite a lot about 
touring. In addition, I enjoyed the challenges of different rigs, various crews, 
and a multitude of troubleshooting opportunities. I was able to grow as a pro- 
grammer and operator. Furthermore, the rush of running lights for a stadium 
filled with fans during a high energy concert is unbelievable and something 
I will never forget. 
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Appendix C 


The Crystal Method Tour: 
A Case Study 


FIGURE C.1_ The Crystal Method Divided by Night Tour. 


In March, I was contacted by my LD friend Lawrence Upton. He told me that 
our favorite band, The Crystal Method, was planning another tour. This was 
their first new tour in nearly eight years, and they were excited to get their 
old team together again to create another vibrant light show. The Crystal 
Method consists of two artists, Scott Kirkland and Ken Jordan, who use a 
host of electronic keyboards and equipment to create rhythmic electronic 
music. Their fans have come to expect an exceptional light show as part of 
their standard performance. 


The Automated Lighting Programmer’s Handbook. DOI: 10.1016/B978-0-240-81553-4.00036-4 
Copyright © 2011 Elsevier Inc. All rights reserved. 187 


188 Appendix | C_ The Crystal Method Tour: A Case Study 


TABLE C.1 The Crystal Method Tour Equipment List 


12 StudioPix 

6 SHOWGUN 

D SHOWBEAM 2.5 
12 Mac 2000 profile 

4 Studio Beam 
18 Atomic Strobe (4 with color scroller) 
2 Axon Media Server 

2 Barco CLM R10+ 

1 Wholehog 3 console with DP8000 
1 Wholehog Playback wing 


The last tour that Lawrence and I put together for them in 2001 was an out- 
standing venture that tapped our creative resources and challenged us to create 
dynamic, ever-changing lighting looks timed perfectly with the music. Typi- 
cally we program at the rate of about | hour of programming to | minute of 
music, which can equate to hundreds of cues within each song. I was excited 
to get the chance to work with Lawrence and the band again and immediately 
began thinking about this show. We began programming a few weeks later in 
Los Angeles, in the exact same venue as eight years before. 

The production this year was to take on a completely different look than 
before. Times had changed and we wanted to include LED fixtures, video 
playback, and other modern equipment that was brighter and more affordable 
than during the previous tours. The actual design of the lighting rig was a 
collaborative effort between Lawrence, the band, and the lighting budget. 
Eventually the result became a ground support system consisting of two 
10-foot-diameter circles with a video screen within each and some lighting 
towers. The fixtures to be used included LED, strobes, hard edge, and wash 
fixtures (see Table C.1). The band would stand on a Plexiglas deck that 
would be underlit with LED fixtures and strobes. 


Lawrence’s Thoughts 


I asked Lawrence to describe his thoughts about this tour: 


The Crystal Method’s music is all about layering. What you need is a range of effects 
that you can manipulate to match the layers of the different sounds the band is playing 
on stage. Brad and I created layers of looks to match the various layers of sounds. This 
is an effects-driven show that maintains a balance between the various lighting fixtures. 
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FIGURE C.2_ Lawrence Upton and Brad Schiller during preproduction. 


One of the philosophies about this show was that it was the first time the band 
wanted to incorporate video images. We looked at two things, LED wall or video pro- 
jection, and we decided to go with projectors. We hired a bunch of video artists to create 
content for us based on our concepts and ideas and then worked with them to produce 
the custom content. Once all the content was loaded into the media servers, I could then 
run that as a lighting cue. During the show, we treated any video content as simply 
another part of a lighting cue. 

We also incorporated LED fixtures for the first time with this band. I feel the LED 
technology is already here in a huge way and it is only going to get better. We still have 
yet to see what can be done with LED technology, but I think this tour was an awesome 
example of it. 


GETTING STARTED 


Once the final design was sent to me, I began the process of determining the 
fixture numbering and the patch. I sat down with my off-line editor and 
added the fixtures (see Figure C.3). Then I came up with a numbering scheme 
for the fixtures that I thought would best suit the programming needs of the pro- 
duction. We were using standard fixtures as well as a few media servers and the 
new StudioPix fixtures from High End Systems. The StudioPix is a combina- 
tion of an LED fixture and a digital light, so the console treats it as three 
“fixtures” in one due to its internal layers. For this production, I started my 
numbering with the brightest hard edge fixtures, then the less bright, then the 
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FIGURE C.3_ A portion of the patch for the tour. 


wash fixtures. Next I numbered the strobes starting at 101, followed by the 
media servers in the 400s. For the StudioPix fixtures, I decided to number 
them by location and by type. So the fixtures on the stage right circle started 
at 611, while those on stage left started at 711. I used my standard numbering 
scheme for digital lights, where 611 symbolized the first fixture on the stage 
right side and its first layer. Its subsequent layers were 612 and 613. The 
next fixture on the circle started at 621 and went though 623. This process 
made it very easy for me to quickly select various fixtures and the correspond- 
ing layer that I desired. 

I consider it very important for a programmer to translate the patching data 
in the console into a format for all on the crew to understand. So I created a 
version of the light plot that contained only the fixture and patch information 
(see Figure C.4). This way, it was easy for anyone to understand what numbers 
were assigned where. I also distributed the standard patch output generated by 
my console, but I find the plot format is always the best choice. 

Since I had the show file started and patched, I then started some additional 
prep work. I created position palettes, pages per song, color palettes, and video 
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FIGURE C.4_ The plot with DMX addressing for The Crystal Method tour. 
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palettes. I also laid out groups and set my preferences. Load in was set in about 
a week’s time and I wanted to ensure I was ready to go. However due to sche- 
duling conflicts, I could not be on site for the first 2 days of load in and setup. 
So I enlisted the help of my friend and fellow programmer Mike Hanson 
to load the show file, test the system, and prepare the video palettes with 
Lawrence. 

During the first two days before I arrived, they went through at least four 
different versions of methods to underlight the band with various LED fixture 
types. In the end, it was decided to keep only the strobes under the deck and 
remove all LED fixtures from this area. In addition, Mike was able to work 
with Lawrence to define stock content from the media servers that could be 
of use. Mike stored these as palettes in the console and also updated my position 
palettes. 


IN THE STUDIO 


Once I arrived, Lawrence and I sat down to discuss our plans. We had a total of 
nine days left in the studio. We not only had to program the show, but we also 
wanted to allocate some time to program a “special feature” for a one-off festi- 
val show that would be at the start of the tour. So we allotted six days to pro- 
gram the 23 songs on our list. The last three days would be for rehearsal/ 
refinement as well as the programming of the festival projection sphere. I cre- 
ated a spreadsheet that listed the song names, date of programming, and various 
other notes (see Figure C.5). As we completed songs, I would update this 
spreadsheet with the date we finished and other pertinent information. This 
greatly helped us to remain on track and to stay organized. 

After this plan was put in place, Lawrence left me alone with the rig for a few 
hours so that I could see what was achievable. I find it a great practice to just pro- 
gram for fun (to different music) and see what the capabilities are with any rig. As 
I did this, I also stored various position and beam palettes as well as customized 
effect engine settings. Throughout the process I created a rather long cuelist full of 
interesting looks and chases. After an hour or so of playing, I went through and 
made sure all my palettes, groups, and default settings were all ready to begin 
actual programming. I had a thorough set of tools to begin the process of program- 
ming the show, so I called Lawrence and we began working on our first song. 

At this early stage of our programming, the band was still shooting and 
working on video content they wanted to use in the show. So we created a cus- 
tom piece of content that served as a placeholder for the actual content. I set up 
the media server with a folder for each song. Then I copied this item into var- 
ious file locations within each folder. This allowed us to utilize the placeholder 
image during our programming. Then later when the actual content arrived, we 
could simply swap the correct files for the temporary files. Again I used my 
spreadsheet to keep track of what content we were expecting to receive for 
each song (see Figure C.5). 


1 Song 
2 |Dark Knight 

3 |Divided by Night 

4 |Roll it Up new mix 
5 |Vapor Trail new mix 
6 |Bad Ass 

@ intro LMFAO - coachella bitch 
6 |Sine Language 

9 |Double Down Under 

10 Come Back Clean 

11 |High Roller 100bprn 

12 |Wild Sweet Cool new Mix 

13 |Born to Slow Morillo edit 

14 |Now is the time 2k8 

15 |Keep Hope Alive new mix 

16 |Busy Child new mix 

17 |thank you text? 

18 |Trip Like | Do 


20 |Cherry Twist new mix 

21 |Name of the Game 100bpm 
22 |Bound Too Long 

23 | Blowout 

24 |Drown in the Now 


Programmed Content Notes 


4-Apr custom installed 

4-Apr done 

4-Apr 

5-Apr. 

5-Jan 

5-Apr 

5-Apr tour content needed 

6-Apr 

6-Apr Sam green screen needed video input 
7-Apr 

7-Apr Sam and Tom green screen needed video input 
8-Apr 

7-Apr 

7-Apr 

7-Apr 

9-Apr 

8-Apr 


9-Apr 
7-Apr Tom green screen needed video input 
9-Apr 
9-Apr 
9-Apr 


FIGURE C.5 The Excel spreadsheet helped with organization during programming. 


Audio 


cD 1-1 
CD1-2 
CD 1-3 
cD1-4 
CD1- 6 
NA 

CD1-7 
CD1-8 
cD1-9 
cD 1-10 
CD3-3 
CD2-1 
CD2-3 
CD2-4 
CD2-5 
M/A 


Orig CD- 3 
cD1-11 
Legion CD -9 
Tweek CD - 10 
New CD-3 
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FIGURE C.7_ The Color Palettes for the show. 


THE PROGRAMMING PROCESS 


Our process for programming each song was a series of five steps. First, Lawrence 
would explain his concepts and goals of the song to me and we would discuss the 
ideas. Next, I would listen to the music and break it down, noting the changes in the 
music and the time in the track when they occurred (see Figure C.8). 
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FIGURE C.8 Songs broken down to a cue structure. 


Third, I would program the lights according the notes I took while listening 
to the music. As I recorded the cues, I would notate the time of the cue from the 
CD track in the cue comment field (see Figure C.9). 

Fourth, Lawrence and I would play through the cues with the music and dis- 
cuss needed changes. Fifth, I would make the changes and then we would play 
through it one more time. 

This process worked extremely well for us and we were able to program about 
four or five songs a day. Of course as with any plan, there were changes. Our days 
were filled with lots of distractions and interruptions. The band was still working 
out the set on stage and making changes daily. Video shoots were going on in the 
studio next door for content, and Lawrence had to be available to assist with these. 
Furthermore, the band was still working on some new remixes of some songs and 
could not provide us with the final music for several tracks. In fact, as we continued 
programming we found it difficult to keep up with which CD contained the most 
recent version of each song. So I added a column to my spreadsheet to notate which 
CD and which track we had programmed each song to (see Figure C.5). This 
proved to be invaluable, as it allowed us to rehearse the songs and reduce confu- 
sion as to which version of which song to use. 

About two days into our programming, we realized that we had a problem. 
Our rig included many very bright fixtures including LEDs and 2500 W spots 
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FIGURE C.9_ A cuelist with CD times notated. 


and washes. We also had a complement of 700 W spots to fill in the underlying 
layer. While the programming of the fixtures was progressing nicely, we 
quickly noticed that the 700 W fixtures just did not have enough punch com- 
pared to the rest of the rig. So Lawrence and I discussed the options and decided 
to ask the lighting company to swap out the 700s for 1200s. This actually 
proved better for the lighting company and the production’s budget, as the 
700s were cross-rented and the 1200s were part of the lighting company’s stock. 

The new fixtures arrived the next day and we came in late after the crew had 
swapped out the fixtures. Then I used the “Change Type” function in my console 
to automatically convert all programming from the 700 W fixtures to the 1200 W 
fixtures. This worked extremely well; I just had to update position, gobo, and 
color palettes to accommodate the fixture change. In addition, the 700 W fixtures 
had an animation wheel that was not in the 1200 W fixtures. So I had to update a 
few cues that had no pattern due to the difference in the fixtures. The change 
proved to be extremely successful, as the secondary layer of lights in the rig 
now could complement the 2500 W fixtures. Thanks to the feature in my desk 
and my preparations with palettes, the change was smooth and easy. 


STILL MORE TO DO 


We continued on with our plans and kept programming song after song. Once 
we had the songs in the desk, then we would end each day by having Lawrence 
play the songs we had programmed, while I would take notes. In order to ensure 
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FIGURE C.10 Completed notes pages. 


we had time to do this, I would set the alarm on my phone about one and a half 
hours before our departure time. When the alarm went off, we would start our 
rehearsal, take the notes, and update the cues as needed. I was always sure to 
keep my notes neat and organized by song. Then as I made the changes I 
would scratch out the note so that I knew it was complete (see Figure C.10). 

In addition, through this rehearsal process, we were able to define the addi- 
tional flash key requirements on the console. Although we had a cuelist per 
song, Lawrence wanted to also have several flash keys to manually override 
and supplement to the looks on stage. We decided to create a “template” 
page that contained a number of generic looks and effects that he could insert 
as needed while playing the cues for the songs. Some songs would also have 
unique looks or sequences on flash keys that overrode the template flash 
keys. Between the console and wing, we had a total of 20 flash keys per 
song. I had Lawrence write out his desired playback template and then I pro- 
grammed the looks accordingly (see Figure C.11). 

We also talked about the best method for updating positions and aligning the 
various video components during each day of the tour. In the past, I have had 
tour operators simply go through the various palettes, load the ones to be 
updated, and make the changes manually. However, I had recently learned of 
a new technique that I wanted to try on this tour. I built a special “Tech Page” 
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FIGURE C.11_ A concept for the flash key layout. 


that contained cuelists specific to the required daily tasks (see Figure C.12). 
There was a cuelist for each fixture type that contained the various position 
palettes used within the show. Additional cuelists allowed for video sizing 
and focus, as well as iris and beam focus for the moving lights. At each 
show, Lawrence and the video crew could easily play these lists and update 
the included palettes with ease. This kept their daily routine well organized 
and reduced confusion and redundant work. 


ONE LAST CHALLENGE 


Even with the various distractions, we were able to get all the songs programmed 
and rehearsed in the time allotted. However, we had one more challenge during 
preproduction. On the second stop of the tour, the band was going to play at the 
Coachella festival in California. They had a concept that tied in with the artwork 
from their recent album. They wanted to have a giant sphere over the stage with 
video projections that matched those of the tour programming. Our tour lighting 
supplier was to provide a 12-foot sphere, four video projectors, and four addi- 
tional media servers. We had planned to use the spherical mapping feature of 
the media server to make the content appear perfectly on the surface of the sphere. 

On the last day in the rehearsal studio, the sphere and projectors arrived. 
I spent several hours working to perfectly align the projectors and media server 
settings (see Figure C.13). However, as Lawrence was anxious to continue 
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FIGURE C.13 Spherical mapping is very challenging. 


rehearsing the lighting, the tension grew with each moment. Due to the 
constraints within the rehearsal space and other factors, I was having diffi- 
culty aligning the spherical mapping. We also realized that this would need 
to be recreated on the festival site in the limited time during the changeover 
before the performance. Lawrence quickly realized that this plan was not 
ideal and that we needed to change direction. So he asked me to stop and 
leave the video setup to the video department and remove the lighting depart- 
ment from the requirements. In the end, this was an exceptional decision. We 
had been trying to do too much from the lighting console, which placed a big 
burden on the lighting staff. So by asking the video crew to be responsible 
for the setup and alignment of the projectors and spherical mapping, we 
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were free to go back to working on lighting cues. The end result worked out 
phenomenally well at the festival, as time was limited and the video and 
lighting departments could work in tandem, instead of the lighting department 
taking everything on. 


ON THE ROAD AGAIN 


After a successful programming period, the lighting for the tour was ready. As a 
final bit of cleanup, I removed the CD times from the cuelists so they would not 
be distracting to Lawrence during the tour. I then went home while Lawrence 
and the band started the tour around the country. At the second stop, I flew out 
for the Coachella festival to help integrate the festival rig with the band’s rig. In 
addition, Lawrence provided me with a few pages of notes from the first 
performance. So as they were loading in, I worked in blind at the console 
and made as many of his requested changes as possible. I also had a chance 
to see the video crew’s work on the sphere and again confirm it was a great 
choice to let them take that on, as I was busy enough without having to 
worry about that. 

After they had completed about 10 shows, they flew me back out to a couple 
of shows to continue helping to refine the looks. By this time, the content crea- 
tors had come up with more content and Lawrence had a good idea of how the 
band was playing many of the new songs or remixes. I arrived at a venue 
directly from the airport and immediately was presented with about 15 pages 


FIGURE C.14 A powerful moment of the show. 
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of notes! Once again, I programmed like mad to get all the changes in before 
show time. Luckily, the load in went smoothly that day and I was able to pro- 
gram right up until doors. Then I rode with them to the next show and again 
made changes and added more cues. Finally, the show was really looking 
great and I again returned home. 

About halfway through the tour they had a stop in Austin, Texas (my home- 
town). I was able to spend the day with them, and again Lawrence had some 
notes and I was able to make the changes. Thankfully, there were fewer 
notes at this point, so it did not take much additional programming and I was 
able to really enjoy the show. 


ONE MORE SHOW 


About six months after the tour ended, I was asked to help with an additional 
The Crystal Method show to be held at a festival in Riverside, California. 
This would be a smaller show with a smaller budget, too; we decided to 
recreate only one of the two circle trusses from the tour. The entire rig 
became one circle truss with six StudioPix, six Atomic strobes, one projec- 
tor, and one Axon media server. A Road Hog Full Boar with wing would be 
used for control. With this small package we could recreate the unique 
visuals expected of the band, and augment with the lighting provided at 
the festival. Luckily, the festival rig designer was very accommodating 
and had a nice-sized festival plot. 

My plan was to clone some fixtures in the festival rig with the fixtures in 
our show file. This way, all our cueing would still be intact. Using the 
“Change Type” function of the desk, this was an easy process that just 
required repatching and some cue updating due to differences in the fixture 
types. I wanted to keep the layering that we had in our original plot, so I 
cloned our SHOWGUN fixtures into the upstage VL3000s. I then cloned 
some of our Mac 2000 profile fixtures to the floor fixtures at the festival, 
which were Mac 2000 washes and VL3000s. Once I updated all the positions, 
it was really cool to see our cues playing back, yet with different fixtures and 
a different layout. I would love to say it was perfect, but in actuality, lots of 
touchup was required. Previously, the SHOWGUNs were the brightest, and 
now the VL3000s were dimmer than the floor fixtures. So I had to lighten 
up colors, open up the beams and irises, and adjust strobe speeds. We had 
about four hours of time with the rig before doors and I was able to get 
the show looking very good. 

The end result was a wonderful-looking show that stood on its own com- 
pared to the other festival acts. The simple fact that we had well-structured 
cues, with various layers of looks (US trusss, floor, and circle truss), really 
defined our production. It is always important at a festival to try to make 
your band have a unique look. With a shared rig, many festivals end up with 
all the bands looking the same lighting-wise. 
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IN THE END 


Working with The Crystal Method is always a thrill, and I am very grateful for 
the opportunity to create a light show for one of my favorite bands. It is not 
often that a band wishes to present the crowd with a massive light show 
throughout the entire performance, and I enjoy the creative challenges their 
music and energy provide. Lawrence is a great friend and a very artistic 
designer; I think that we make a dynamic team capable of achieving great 
looks and effects. Having worked with The Crystal Method and Lawrence 
for over ten years has certainly been a blessing of my career, and I appreciate 
all that I have learned from both. Hopefully we will continue to wow audiences 
with dramatic combinations of electronic music and ever-evolving lighting 
shows for years to come. 


FIGURE C.15 The Crystal Method show with its many layers. 
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Glossary 


8-Bit DMX A parameter that uses a single DMX channel for control. 

16-Bit DMX A parameter that uses two DMX channels for control. Usually used with pan 
and tilt for finer resolution of control. 

ACL, Aircraft Landing Light An extremely narrow beam PAR lamp that has a higher 
brightness and color temperature than a standard PAR lamp. 

ACN, Architecture for Control Networks An industry standard for sending and receiving 
fixture data over Ethernet networks. 

Art-Net A proprietary protocol for sending DMX data over Ethernet networks. 

Automated Light A remotely controlled lighting fixture, usually with the ability to move 
and/or change colors. 

Ballyhoo A programmed move of automated lighting fixtures where the lights are seen to 
move randomly within a defined area. 

Bank See Page. 

Beamage A term used to describe beams of light projected from lighting fixtures as seen in 
the air. 

Board See Console. 

Bump To change the value of a parameter at a time of 0. Usually assigned to a momentary 
button on the lighting console. 

Bump Button A button on a lighting console that creates an action when pressed and another 
action when released. Also referred to as a Flash key. 

Chase A looping set of cues or steps. 

CMY, Cyan Magenta Yellow A color-mixing methodology based on adjusting filters of 
specific wavelengths. 

Console A custom developed input control device used for programming lighting. 

Conventional Light A nonautomated lighting fixture, usually working in conjunction with 
dimmers. 

Crossfade A timing value assigned to fixture parameters used to control the duration of a 
change from one DMX value to another. 

CTB, Color Temperature Blue A color filter that raises the color temperature of a fixture’s 
output near 7000 K. 

CTO, Color Temperature Orange A color filter that lowers the color temperature of a 
fixture’s output near 3200 K. 

Cue The basic placeholder in a lighting console for all programming data. Often also referred 
to as step, look, or clip. 

Cuelist A series of cues intended to play back in a particular order. Also referred to as 
sequence or stack. 

Desk See Console. 

DHCP, Dynamic Host Configuration Protocol A computer networking protocol that 
automatically assigns IP addresses. 
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Digital Light A remotely controlled lighting fixture that uses nonmechanical methods 
(usually video output) to create and modify the output of the fixture. 

Dimmer A device used to control the intensity of incandescent lighting fixtures. 

DMx, Digital Multiplexing A programming protocol commonly used by lighting products. 
The protocol consists of 512 channels each with 256 values. Generally, a single channel 
controls one function of an automated lighting fixture. 

DMX Address The starting DMX channel used by a lighting fixture or dimmer. 

DMX Universe A DMX universe contains 512 channels of control. Often referred to as a 
world or output. 

Effects Mathematical calculations used by a lighting console or fixture to create premade 
chases. 

Ethernet A computer network methodology for delivering data between devices. DMX is 
often converted to an protocol transmitted via Ethernet to allow for data distribution. 

Fader A device on a lighting console to allow for manual crossfades of parameters. 

Fixture A lighting instrument. 

Fixture Number The number used by a lighting programmer to access a particular fixture 
during programming, usually different than the DMX address of the fixture. 

Flyout A programmed move of automated lighting fixtures where the lights are seen to move 
vertically from one position to another. For example, a typical flyout cue moves fixtures 
from the stage to above the audience. 

FOH, Front of House The location of the lighting and sound consoles is referred to as FOH 
because it is generally located in the audience areas. 

Gobo A piece of metal or glass that is placed between the lamp and lens of a lighting fixture. 
Gobos are used to project images and shapes. 

Grand Master A fader on a console providing the ability to reduce intensity of the console’s 
output. The grand master has priority over all other intensity functions of the console. 

Group A stored array of lighting fixtures within a lighting console. The selection of groups 
aids in quick fixture selections during programming. 

GUI, Graphical User Interface An input methodology that allows users to input data other 
than via a keypad. 

Hard Edge Light A lighting fixture capable of focusing on an image such as a gobo or 
framing shutter. This type of fixture is primarily used for projection of images and shapes. 

HTP, Highest Takes Precedence A console function that gives priority to the highest 
numeric values of fixture parameters, regardless of when they are changed. 

Inhibitive Master Similar to a grand master, but only works with a defined set of fixtures. 

LD Lighting Designer. 

Look See Cue. 

LTP, Latest Takes Precedence A console function that gives priority to the most current 
changes to fixture parameters regardless of their numeric values. 

Media Server A DMX-controlled computer system used to play back and manipulate video 
and still images. 

MIDI, Musical Instrument Device Interface A commonly used protocol for triggering 
consoles or other devices. 

Node An electronic device that is attached to a network that is capable of sending, receiving, 
or forwarding information over the network. 

Operator A person who is responsible for playback of cues on a lighting console. 

Page A term used to describe a series of cuelists laid out in an organized fashion. Multiple 
pages are often used to allow for a greater number of playbacks on a console. 
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Palette A reference to specific values of fixture parameters. Palettes can be recorded into cues 
in place of actual parameter values. Some consoles refer to this as a preset. 

Parameter A function of a lighting fixture is referred to as a parameter. 

Patch The information in the console that relates the fixture numbers to the DMX addresses 
of the lighting fixtures and dimmers. 

Playback The function of recalling stored information from a console. 

Plot A diagram of the lighting fixtures and their placement. Usually also contains information 
regarding DMX addressing of the fixtures. Also referred to as a plan or drawing. 

Preset Depending upon the console type, this word has several uses. See also Cue and 
Palette. 

Programmers The best people on Earth! 

Programmer (Window) A screen or window on a lighting console that displays the 
currently edited information. 

Rate The speed of a chase or effect. 

RDM, Remote Device Management An extension of the DMX protocol that provides 
feedback data and configuration of fixture parameters. 

RGB, Red Green Blue A color-mixing methodology based on adding specific wavelengths 
of light. 

Rig The entire lighting system, including mounting points, trussing, fixtures, and console. 

Sequence An organized list of cues or steps. 

Show Control External triggers used to send commands to or from a lighting console. 

SMPTE, The Society of Motion Picture and Television Engineers A professional body 
that sets and defines technical standards. Their timecode format is referenced in this book. 

Timecode Timing information embedded onto audio or video tracks. 

Timing Values applied to crossfades of lighting fixture parameters. 

Tracking A console function where only changed values are recorded into cues. A value will 
remain the same until it is changed by another cue or console function. 

UPS, Uninterruptible Power Supply An electrical device that provides emergency power to 
a system when the main power source fails. 

Visualizer A software platform used with a lighting controller to graphically emulate real- 
world lighting situations. 

Wash A lighting area or look designed to completely cover the stage or surface with color or 
gobos. Derived from the phrase “bathed in light.” 

Wash Light A lighting fixture not capable of focusing on gobos or framing shutters. This 
type of fixture is primarily used for broad strokes of color. 
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ACN (Architecture for Control Networks), 16 
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Advanced programming, see Programming, 
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Amateur programmers, | 
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Automated lighting programmers, 1-6 
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setup for, 15-16 
software and, 15-16 
understanding, xxiii, 31-33 
see also Cues; Digital lighting: Fanning 
FOH (front of house) power, 17, /8, 
107, 114 
Frame rate parameters, 83 
Frank, Laura, 133-134 
Front of house (FOH) power, 17, /8, 
107, 114 
Frost, 32 
Fyssicopulos, Demfis, 134 


G 

Gaff, Craig, 134 

Garner, Steve, 134 

Genres, see Programming genres 
Global layer parameters, 83 

Gobo rockers chases, 57 

Gobos, 31-32, 34, 35, 42, 50, 109 
Griffin, Jon, 134-135 

Grivas, Tim, 135 

Groups, 22-25 


H 

Halliday, Rob, 135 

Handles, 21-24, 22 

Hartley, Bryan, 135-136 

Highest takes precedence (HTP), 11 
Hollywood syndrome, 2-3 
Horowitz, Bud, 136 

Howell, Wayne, 96 

HTP (highest takes precedence), 11 


Ice skating competitions, 45, 110 

Indigo/red chases, 57 

Intensity effects, 32, 42, 51-53 

Intermediate programming, see Programming, 
intermediate 


Index 


Iris, 50-51, 5/, 54-56 
Irwin, Steve, 136 


Jackson, Seth, 136-137 
Jacobson, Mark ‘Junior’, 137 


January, Shannon, 137 


K 

Kaniski, David “Gurn’, 137-138 
Karlson, Mats, 138 

Kennedy, Eric, 138 

Kenny, Tom, 138 

Keystone parameters, 83 

Kicks chases, 56 

Knox, Hillary, 138-139 

Kroémer, Marcus, 139 


L 
Latest takes precedence (LTP), 11 
Layer parameters, 83 
LCDs (liquid crystal displays), 16, 79 
LDs (lighting designers), 2, 113, 123-125, 
128-129, 131 
see also individual names of LDs 
LEDs, xxiv, 16, 87, 89-93 
Lenahan, Jim, 139-140 
Lieberman, Steve, 140 
Lighting designers (LDs), 2, 113, 123-125, 
128-129, 131 
see also individual names of LDs 
Lima, Esteban, 140 
Line chases, 57 
Liquid crystal displays (LCDs), 16, 79 
LTP (latest takes precedence), 11 


M 

Maintenance of architectural installations, 
115-116 

Mark cues, 41-44 

Marrinan, Heath, 140-141 

Mask parameters, 84 

Mathematics, see Effects generators 

Media, 80-82 

Media servers, 82-83, 86 

MIB (move in black), 42-43 

MIDI (Musical Instrument Digital Interface), 
72-16, 73, 75-76, 104 

MIDI Show Control (MSC), 72-76, 
75-76, 104 

Mode channels, 9-10, 33, 114-115 

Monitors, 109 
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Move in black (MIB), 42-43 

MSC (MIDI Show Control), 72-76, 76, 104 

Multi-user programming, 96-97 

Music festivals, 111-113, /// 

Musical Instrument Digital Interface (MIDI), 
19, 72-76, 73, 75-76, 104 


N 

Natural lighting conditions, 5 
Networking, 73, 98-99, 119 
Nevitt, Michael, 141 

Ngieng, Adrian, 141 
Nontracking consoles, 11-12, /2 
Normandale, Paul, 141 


O 

Ohrberg, Jim, 141-142 

One-off shows, 38, 45, 111-113, 1/1 
Operator error, 119-120 

Outlines, 25 

Owens, Steve, 142 


P 
Pages, 107 
Palettes 
basic programming and, 37-39 
color, 25, 39 
default, 64 
intensity, 42 
position, 25, 37-38, 38, 106 
visualization, 68 
Pan and tilt, 16, 32-33, 58-59, 58-59, 65 
Parameters, 10-11, 31-35, 50-53, 60-61, 6/, 
83-88 
PARs (parabolic aluminized reflector lamps), 58 
Patches, 19-21, 20, 22, 35-37, 87 
Peebles, Mitch, 142 
Pelletier, Paul, 142 
Philosophies, 1-6 
Pixel mapping software, 92-93, 93 
Pixelation Luminaires, 91-92 
Position palettes, 25, 37-38, 38, 106 
Position parameters, 84 
Precedence, 11 
Presets, see Palettes 
Problems, 117-122 
Programmers, 1-6 
see also individual names of 
programmers 
Programming, advanced 
default values and, 63-66 
midi and, 72-76, 73, 75-76 
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Programming, advanced (Cont.) 

other automation methods for, 76-77 

timecodes and, 69-72, 70-71 

visualization and, 66-69, 69 
Programming, intermediate 

basic programming concepts and, 53-56 

common chases and, 56—58, 57 

cues and, 41-46, 45 

effects generators and, 46-51 

fanning and, 58-59, 58-59 

fixture selection order and, 59-61, 60-61 

intensity effects and, 42, 51-53 
Programming basics, 31-39 
Programming genres 

architectural installations, 113-116 

concert tour, 104-107, 1/05 

music festivals and one-offs, 111-113, /// 

structured and corporate theatre, 101-104, 

102 

television event, 107-111, 108 
Programming philosophies, 1-6 
Programming preparation 

consoles and, 16-19, /8 

fixture setup and, 15-16 

groups and, 22-25 

numbers and, 21-22, 22 

outlines and, 25 

planning and, 29 

preparing the patch and, 19-21, 20 

protection of work and, 25-29, 28 
Protection of work, 25-29, 26, 28, 97, 115 


R 


Rainbow color chases, 57, 57 

Random strobe chases, 57 

Raster parameters, 84 

Rayment, John, 142-143 

RDM (Remote Device Management), 16, 29, 99 

Relationships between programmers and LDs, 
123-125, 128-129, 131 

Remote access, 98-99 

Remote Device Management (RDM), 16, 29, 99 

RGB cells, 90-91 

RGB mixers, 89-90 

Richard, Benoit, 143 

Riley, Scott, 143-144 

Robbins, Larry “Uncle Fester”, 144 Rock Solid 
Ethernet (Howell), 96 

Rogers, Timothy F., 144 

Rose, Susan, 144-145 

Rotate speeds, 33 

Rotating gobos, 33 


Index 


S 

Safety, 120-122 

Scale parameters, 84 

Schiller, Brad, 69 

Scrollers, 43-44 

Serame, Arnold, 145 

Servers for digital lighting, 82-83 

Set lists, 107 

Setup cues, 41-44 

Shape parameters, 84 

Show control computers, 72-76, 75-76, 104, 115 

Shutter strobes, 32 

Sine waves, 47-49, 48-49, 52 

Single-channel fixtures, 36 

Smooth color mix chases, 57, 57 

SMPTE (Society of Motion Picture and 
Television Engineers) timecode, 16 

Snap changes, 10, 13 

Software, 15-17, 19, 66-69, 69, 92-93, 93, 98 

Speed channels, 33-35, 35 

Split times, 37 

Splitters, 118 

Stabs chases, 57 

Stand-alone modes, 114-115 

Stern, Marsha, 145 

Strobes, 32, 51-53, 57, 60 

Sume, Henry M., 145-146 


T 
Television events, 107-111, 108 
Terminators, 117 

Texas Instruments, 79 

Theatres, 42, 101-104, 102 

Tilt functions, 16, 32-33, 58-59, 58-59, 65 
Timecodes, 17, 69-72, 70-71 

Timing parameters, 33-35, 60-61, 6/ 
Tracking, xxiv, 11-14, 12-/3 

Trails parameters, 84 

Training, 4 

Triggering methods, 72-76, 75-76, 104 
Trigonometry, see Wave forms 
Troubleshooting, 117-122 


U 

Ungerleider, Howard, 146 

UPS (uninterruptible power supply), 17 
Upton, Lawrence, 69, 146 


V 

Video displays, 92 

Visual effects parameters, 84 
Visualization, 66-69, 69, 98 


Index 


W 

Wave forms, 47-50, 48—50, 52 

Weekend warriors, 1 

Weir, Jon “Hillbilly”, 146-147 

Williams, Ross, 147 

Wireless networking, 98-99 

WYSIWYG (What You See Is 
What You Get), 66 


X 


X rotation parameters, 84 


Y 


Y rotation parameters, 84 


Z 


Z rotation parameters, 84 
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